Fork me on GitHub

Is it possible / advisable to get the active deps.edn alias(es) from the Clojure code invoked by them? For example, to access app-specific settings defined in that alias?


@cap10morgan look at clojure.basis system property

👍 3

I think it's OK some of the time to do that, yeah.


I do it to identify build directories, for example, so I can stop them being refreshed


@cap10morgan You can't tell what aliases were used to invoke your code but, as Dominic says, you can read the basis file in -- if you were started via the Clojure CLI.

👍 3

The basis is not available for code running via java -jar etc.


I haven't actually looked, but I thought the active aliases were in the basis.


Yes, all merged aliases are in the basis. So you can slurp it, read the EDN, and then navigate to :aliases -> any alias.


I'm thinking it would be nice, when building an uberjar, to be able to read the basis and write it into the JAR as a resource that could be read at runtime.


I mean the activated ones though. Currently rebuilding my computer so I can't check :)


Not sure what you mean by "the activated ones"?


Knowing that -A:dev was called, for example


The basis is the merged deps.edn (and command-line) stuff, plus :libs and :classpath etc. No, you cannot tell what aliases were used for invocation.


it looks like what I want is in :resolve-args of the basis. thanks!


Does that actually include the aliases used? Or just the result of processing those aliases?


A quick test locally shows that :resolve-args of the basis has keys :override-deps :extra-paths :extra-deps :main-opts :jvm-opts -- so that's not the aliases, just the result of the aliases @cap10morgan


Yeah, the result is what I want. I have app-specific keys in one or more aliases and I want to access the ones that got activated. I don't actually care which alias key(s) did it.


@cap10morgan I'm confused. What "app-specific keys" are you talking about?


well, in general, anything you want that doesn't step on something already defined. So, for my case, I'm using :pom2project/injections.


Alongside the :extra-deps, :main-opts, etc.


Ah, so you're outside the bounds of what deps.edn and t.d.a support there.


It just happens to work right now but I doubt that is guaranteed...


@alexmiller Can it be relied on that :resolve-args will contain any and all keys from the merged aliases selected, not just the known, supported keys?

Alex Miller (Clojure team)19:12:01

aliases (that are used to modify resolve-deps and make-classpath) are a feature of the clojure script, not of tools.deps or the basis

Alex Miller (Clojure team)19:12:31

that is, they are just a mechanism with which to convey :extra-deps etc. if you look at something like calc-basis, it does not take or return anything related to aliases

Alex Miller (Clojure team)19:12:42

if you want to read data from an alias, I would encourage you to convey the aliases to use via an argument, read the deps.edn (or calculate a basis), and extract the aliases that way. relying on stuffing extra stuff into the aliases used to make classpaths is probably not a good idea


Thanks, Alex. That's a good clarification (feature of the Clojure CLI script -- rather than t.d.a), and another reason why the "selected aliases" information is not available in the running program.


^ @cap10morgan Does that change how you feel about adding unknown keys in aliases?


Thanks for that background. For now this approach makes the most sense for what I need so I'll probably stick with it. If I have to change it later, no big deal. Strictly for internal tooling for now.