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

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.

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?

I'll say undefined :)

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

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

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.