This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2024-02-15
Channels
- # announcements (1)
- # babashka (1)
- # beginners (43)
- # cider (2)
- # clj-kondo (29)
- # clojure (61)
- # clojure-austin (18)
- # clojure-dev (7)
- # clojure-europe (30)
- # clojure-nl (1)
- # clojure-norway (23)
- # clojure-uk (5)
- # clojuredesign-podcast (8)
- # cloverage (1)
- # conjure (1)
- # data-science (1)
- # datahike (36)
- # datavis (1)
- # datomic (23)
- # emacs (14)
- # hyperfiddle (28)
- # lsp (5)
- # missionary (1)
- # music (1)
- # off-topic (11)
- # re-frame (11)
- # reitit (5)
- # releases (1)
- # shadow-cljs (65)
- # spacemacs (13)
- # squint (33)
- # tools-deps (56)
What's a good way of getting the computed :paths for a set of aliases?
I'm seeking for XXX
here which would mean "print the computed deps.edn contents after applying these aliases"
clojure -A:dev:test XXX | jet --thread-first :paths
but currently the CLI doesn't print the basis. -Sbasis
might be a nice option for this.
There is an issue for this at https://github.com/borkdude/deps.clj/issues/122 - but wondering if the official CLI has opinions about this
Thanks! I was surprised not to find something like -Sbasis, that had me questioning my own sanity/eyesight
Yeah, nothing for that at the moment, feel free to add to ask.clojure
The basis of course is a file in your cpcache so it’s just printing that
Will ask
:)
A file is tempting but considering that it's a function of the aliases, it can feel fragile for end users?
I know the tools jar is putting that file in .cpcache but is there a (formal) way to get the current .cpcache hash / basis file printed by the CLI?
I mean, implementing this would just be printing that file. There is no such functionality now but would be happy to add it
yeah, that would be cool and fix @U45T93RA6’s question and the open issue with deps.clj posted by @U0567Q30W
https://ask.clojure.org/index.php/13739/option-in-clojure-cli-command-to-print-the-basis
thanks. I posted two suggestions, either add the cache hash to -Sdescribe (or add the full path to the basis file), or add a -Sbasis option. FWIW 🪙
You can find the hash via -Sverbose btw, but will add -Sbasis
That would be super useful for me, and I think resolve that outstanding issue. @U04V15CAJ Sorry I haven’t had a chance to look at that yet, perhaps waiting will just make the problem go away 🙂
I think that’s actually the only thing I need the paths in that issue for, but I’ll have to check.
Either would be fine, but (having not thought it through very carefully yet) I think that EDN probably makes more sense and would be useful for more tools. But the EDN is just a slurp away given the path, so either would work for me.
would it be useful to have programmatic access to the hash as well (vs the output that is now in -Sverbose
)?
Again, I’d have to check, but I believe the only thing I use that for is accessing the basis.
I do not consider the hash normative in any way and would not want to pretend it something you should care about
I've tried hard to keep that in the domain of the CLI script and out of tools.deps world
yeah, the hash would just give access to anything you'd be interested in inside of .cpcache for the combination of relevant arguments, but I guess that's also an impl detail
having thought about it more, prob more interested in something like clj -X:deps basis
than clj -Sbasis
but I don't think that matters for this purpose
the difference here in caching may be important though as the former would leverage caching but the latter wouldn't. does this matter?
I think it would be helpful if a -Sbasis
call with the same arguments would not invoke a JVM again
Yes, definitely, I would assume that it would just return the cached version if that exists (assuming -Sforce isn’t used.
Ok, looking at my code, I definitely need the basis, and either a path or EDN would be fine. I also return the path to the installed tools jar and the install dir, but I just use those to extract the system deps.edn to the install path so I have it on the file system. Some other way of obtaining the system deps.edn file would be useful too so I don’t have to do that.
-Sverbose
gives:
config_paths = /opt/homebrew/Cellar/clojure/1.11.1.1273/deps.edn /Users/borkdude/.clojure/deps.edn deps.edn
not sure if that is inside the basis as wellOh, I didn’t realise the system deps was already extracted to the file system. But yeah, I’ve avoided parsing -Sverbose output so far.
there is an api call you make in tools.deps to get the root deps
that config_paths above is actually lying a bit - the root deps.edn there is not the one being used (although it exists and should be the same)
Right, the actual file is extracted as a resource IIRC. What I’ve been doing is extracting the resource and writing it to install-dir if it doesn’t exist there.
IIRC under deps.clj that file is not extracted, but perhaps I checked before tools.deps got called to do the extraction.
I remember vaguely that there was some logic in the bash CLI clj script which I also implemented in deps.clj to copy some .edn file to the install dir, is that what you are referring to?
that's the user deps.edn, which is effectively empty
or the tools install
yeah, that installs the tools tool
in any case, none of this is relevant to the root deps which ultimately comes from the tools.deps jar
Would it be a good idea to put them there? Then I think -Sbasis would do everything I need without any internal implementation fishing, which I would be very happy about 🙂
well, there is no path for the root deps
using the CLI, the only path for project.clj is the "./project.clj"
user deps is more complicated, but all of these have existing api calls in tools.deps
the deps config sources WILL be in the :basis-config if they are something other than the defaults
(which they never are for root or project)
:basis-config is the same map of params you can pass to all the :deps alias programs and https://clojure.github.io/tools.deps/#clojure.tools.deps/create-basis