Clojurians Log v2

Are there any plans to support data-readers in deps.edn :args data?

The use case is defining overrides for an integrant system, allowing #ig/ref. Obviously it’s also easy to put that system in a separate file, and read that, so not a big deal, and I can imagine that it’d add complexity to tools.deps. Just curious.

I don’t think there’s any need for that

Or do you mean for data in aliases in deps.edn?

for context #ig/ref creates a record type. I suspect Rick is trying to pass in the integrant system to run via deps.edn aliases.

when you use -X the alias data is actually loaded in the context of the program you're running, so the data readers available via data_readers.clj[c] are available (but not currently being used in the edn/read, so seems like this shouldn't be too hard

Yeah it’s for data in aliases

And yeah I was thinking the same, using data_readers.clj(c) would be great for this.

I will log a jira for this, seems a reasonable thing to want

@dominicm’s suspicions are right… Essentially I’m writing a script, that wants to leverage some integrant components pre-defined in libraries. I currently have the system defined in a var in my program, and it would be useful to be able to override some of the components configs via args. I could obviously just put it in a separate edn config file; but it’s another config file (sigh) for something that’s intended to be pretty minimal.

yep, got it

It would be fab if tools.deps could do this… it’d make configuring and overriding bits of integrant systems much nicer.

Though I warn you, it’ll be a slippery slope, I’ll probably next want data aliases and command line args to be meta-merged 😆

https://clojure.atlassian.net/browse/TDEPS-163

what does "meta-merged" mean?

I'm guessing you mean deps.edn and -Sdeps alias data merged?

those will be merged now, but perhaps not in the way you want :)

Well I was just joking about supporting meta-merge 🙂 But I meant: https://github.com/weavejester/meta-merge which is very useful for doing deep merges of data. We tend to structure our integrant systems into profiles that get applied and meta-merged in a certain order.

So in a tools.deps meta-merge context you could have data aliases for each of those profiles, and meta-merge them all together in the specified order, with -Sdeps and command line args on top etc. I was only joking though assoc-in makes more sense for tools.deps.

well, that's there for -X with an :args map and pathed data on the command line

I'm not going to use meta-merge on deps data, but your program can combine data from multiple aliases that you load in any way you want

by loading it via the runtime basis

:thumbsup: Ahh yes that’s true — I’d forgotten I could do that.

I think that would work quite nicely actually :thinking_face:

https://clojure.org/reference/deps_and_cli#_basis_injection

I already have it slurped in my REPL 😁

Thanks

I guess that code could use data readers too :)

Yeah was just going to ask about that

:thumbsup:

edn/read-string takes an optional opts map where you can pass :readers

(def basis (edn/read-string {:readers *data-readers*} (-> (System/getProperty "clojure.basis") jio/file slurp)))

something like that?

yeah that would work nicely with TDEPS-163

there are other places that edn/read-string that you don't control, so those should do this too

inside tools.deps (deps reader) and the exec stub (command line)

Yeah I can’t do anything without TDEPS-163 also supporting the readers properly

I probably won't get to it today, but it shouldn't be a big deal

No rush, but it’ll be great to see this

Other use cases for us are that we like to represent URIs as data, not strings… and we have quite a lot of URIs in config data.