This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-02-21
Channels
- # announcements (7)
- # babashka (16)
- # beginners (174)
- # biff (7)
- # calva (20)
- # cider (3)
- # clerk (6)
- # cljsrn (4)
- # clojure (98)
- # clojure-europe (57)
- # clojure-italy (3)
- # clojure-nl (1)
- # clojure-portugal (1)
- # clojure-spec (15)
- # clojure-uk (7)
- # code-reviews (3)
- # cursive (23)
- # data-science (1)
- # datomic (26)
- # dev-tooling (2)
- # emacs (5)
- # figwheel-main (4)
- # fulcro (3)
- # honeysql (20)
- # hyperfiddle (20)
- # malli (8)
- # membrane (31)
- # nextjournal (5)
- # pathom (1)
- # polylith (20)
- # re-frame (14)
- # reitit (8)
- # releases (2)
- # shadow-cljs (50)
- # specter (2)
- # sql (22)
- # xtdb (5)
Does (or could) babashka support https://clojuredocs.org/clojure.core/load? Further context about this here: https://clojurians.slack.com/archives/C053AK3F9/p1676959183204429
There's a discussion about combining/separating namespaces in Clojure that may be https://clojurians.slack.com/archives/C03S1KBA2/p1676505742985569.
Yeah - I’m having a lengthly discussion with some of the same participants right now. If we can have load
in babashka, we can avoid using potemkin and really just follow the pattern from clojure.core.
clojure.core
is basically the only namespace I've seen following that approach. Most end up having multiple namespaces.
Yeah, I just don’t like requiring so many namespaces. I’m really glad clojure core doesn’t also make me do that.
Could your IDE help do it for you automatically? In Java every single class is imported from a different file - but IDEs handle it all for the user without them having to care.
Sure, it can be done with some emacs foo. I’d just rather avoid it all together. It seems like this is part of why load
exists in the first place.
It might actually be a nice additional feature for the clojure language which is some project level require definitions that apply to all namespaces automatically.
Yeah that’s true - like require my-namespace/*
I’m sure there would be a very healthy debate about that though 🙂
What’s nice about the load
/ in-ns
pattern is that it sort of “splits the difference”. You still need to be “explicit” - but you can get things combined into a single NS where you want to.
Babashka has a function load-file
but I don't think that's the same. You maybe be able to build on top of that though depending how it works.
Yes - the issue I ran into with load-file
was this it’s relative to where executed from.
(otherwise it would have been fine indeed)
You may be able to wrap around the load-file function - potentially even reading the file and generating modified temporary files that you load.
It's possible that you can work out the relative path (.getAbsolutePath (
Ooh that’s true. Really though, https://github.com/clj-commons/potemkin solves this problem in a way that works with babashka. If I can use a core feature to replace potemkin though, I’d prefer that.
If you ended up here, please see near the bottom of the linked thread. This turns out to be unnecessary and can be achieved by simply using in-ns
in your “helper files”.