Fork me on GitHub
#tools-deps
<
2022-08-09
>
mpenet07:08:52

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

mpenet07:08:08

was it ever considered even

mpenet07:08:00

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).

mpenet07:08:31

short of forking tools.deps to add support for this directly this is not currently possible

mpenet07:08:03

it's worth noting aero has 0 dependencies, so the price would be small (vendoring these few litterals is also quite easy)

nivekuil07:08:48

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

nivekuil08:08:26

not sure what you need it for but could you generate what you need from tools.build?

mpenet08:08:08

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.

mpenet08:08:16

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

mpenet08:08:35

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.