This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-08-09
Channels
- # announcements (3)
- # babashka (120)
- # beginners (87)
- # calva (7)
- # clj-kondo (35)
- # cljsrn (25)
- # clojure (94)
- # clojure-austin (4)
- # clojure-europe (53)
- # clojure-nl (2)
- # clojure-norway (6)
- # clojurescript (16)
- # conjure (8)
- # cursive (6)
- # data-oriented-programming (2)
- # data-science (19)
- # datahike (1)
- # datalevin (29)
- # datomic (13)
- # fulcro (50)
- # gratitude (1)
- # honeysql (9)
- # jackdaw (2)
- # kaocha (7)
- # leiningen (3)
- # malli (4)
- # off-topic (4)
- # polylith (3)
- # re-frame (5)
- # reagent (1)
- # releases (1)
- # reveal (4)
- # shadow-cljs (17)
- # tools-deps (10)
- # vim (17)
- # vscode (4)
- # xtdb (3)
is there a way the tagged litterals support in tools.deps deps.edn reading could be opened to customization somehow? It's a bit a trick question as it would require to allow to express where to find the functions behind these
I know I asked this before but I never really got an answer. I am dreaming of having something similar to what aero provides for deps.edn files (literals for including other edn files in locations, pointing to other key values in the file, basically aero #include #ref and #merge).
short of forking tools.deps to add support for this directly this is not currently possible
it's worth noting aero has 0 dependencies, so the price would be small (vendoring these few litterals is also quite easy)
when I tried aero I didn't really get the benefits of having this custom clojure-like DSL and it was annoying how it behaved (iirc with #merge and #ref combined). I would rather just write clojure that generates edn
not sure what you need it for but could you generate what you need from tools.build?
I currently do that, write clojure that generates edn, but it's cumbersome. We also wrote libraries to make this easier for mono-repos/multi-modules setups.
composing edn files and enabling more dynamism is powerful, we use that a lot at work. That's one of the strengths of edn to allow these kind of things from the user
with stuff like #ref #include & #merge you'd basically open the door to complex monorepo like setups (dependencies version sharing, alias sharing etc) with 0 file generation and no alias juggling at invocation time. And on top of being quite lightweight, that'd purely be opt-in, if you don't care about it you don't have to use it.