This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-12-01
Channels
- # adventofcode (66)
- # announcements (12)
- # aws (8)
- # babashka (28)
- # beginners (160)
- # cider (28)
- # clara (22)
- # clj-kondo (5)
- # cljdoc (40)
- # clojure (129)
- # clojure-australia (2)
- # clojure-europe (24)
- # clojure-gamedev (19)
- # clojure-nl (5)
- # clojure-norway (15)
- # clojure-sanfrancisco (25)
- # clojure-seattle (2)
- # clojure-spec (13)
- # clojure-uk (29)
- # clojurescript (14)
- # cryogen (5)
- # cursive (7)
- # data-science (1)
- # datascript (5)
- # datomic (8)
- # deps-new (5)
- # emacs (19)
- # events (8)
- # fulcro (32)
- # graalvm (7)
- # helix (9)
- # kaocha (3)
- # lambdaisland (1)
- # london-clojurians (4)
- # malli (5)
- # meander (32)
- # off-topic (143)
- # pathom (4)
- # portal (32)
- # re-frame (7)
- # reagent (33)
- # reitit (2)
- # shadow-cljs (5)
- # spacemacs (4)
- # tools-deps (30)
- # vim (1)
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?
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.
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"?
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.