This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-03-10
Channels
- # announcements (3)
- # asami (4)
- # babashka (21)
- # beginners (97)
- # calva (32)
- # cider (4)
- # clj-kondo (7)
- # cljdoc (1)
- # clojure (70)
- # clojure-europe (27)
- # clojure-nl (10)
- # clojure-norway (18)
- # clojure-uk (8)
- # clojure-ukraine (1)
- # clojurescript (5)
- # datalevin (7)
- # docker (1)
- # emacs (3)
- # fulcro (4)
- # girouette (4)
- # graalvm (2)
- # graphql (9)
- # gratitude (3)
- # honeysql (4)
- # hoplon (3)
- # hyperfiddle (7)
- # jobs (3)
- # kaocha (31)
- # lsp (23)
- # malli (7)
- # missionary (6)
- # nextjournal (9)
- # off-topic (6)
- # pathom (13)
- # polylith (13)
- # practicalli (3)
- # remote-jobs (3)
- # reveal (7)
- # schema (1)
- # sci (23)
- # shadow-cljs (31)
- # tools-deps (62)
- # xtdb (8)
would it make sense to have a property babashka.config
that contains the location of the active bb.edn
? I could use this right now to locate resources relative to bb.edn
when calling from some other place using --config
- so kind of like babashka.file
but for tasks?
For your use case it may not be necessary, as the classpath is set according to the config
but i’ve noticed that neither *file*
nor babashka.file
seem to be helpful in the task context, so maybe it’s worth considering nevertheless (although i realize babashka.task
is available to detect whether we’re in task)
The benefit of a function would be that you don't have to set the property when nobody uses it
fwiw i would be less surprised to find that info in a property, it seems consistent with what’s already there
yes, the same is true for babashka.file but this was a progressive insight. the least amount of work we have to do at startup, the better