Fork me on GitHub

Hey 👋 We’d like to bring in modules from another private repo using gitlibs. Ideally we’d want to use ssh auth. There’s no way to add support for another coordinate or get it to use tools.gitlibs from without forking tools.deps (and having to distribute it to everybody on the team), is there? Or any other solutions to this problem that folks can recommend? Thanks!


If all else fails, you could manually pull the code and add it via local/root?


yep, guess that’s one option. Was also looking at your since we do require babashka on the project but the compute classpath part still happens on the jvm using the normal t.d.a jars right?


it pulls tools jars that are exactly the same as the jars that clj uses. however, we could make that configurable ;)


but maybe best to not create forks of official tools when it can be fixed in those official tools


hi please advice - is there a way to include some java source files and use it from the clj? for instance I want ot have this file used is it possible to achieve with a c.t.d.? thanks!

Alex Miller (Clojure team)14:10:31

you can compile the java source into java class files, then add the path containing those to your paths

Alex Miller (Clojure team)14:10:11

you can either use javac (the Java compiler) directly or there are various tools available to help with that


i see, thanks for the options


would it be an idea to extend -X with being able to pass a single map?

clj -X:graph graph :deps '"mydeps.edn"' :trace true :output '"trace"'
clj -X:graph graph '{:deps "mydeps.edn" :trace true :output "trace"}' 
The quoting of strings seems a little clumsy on the command line, so quoting the entire map can deal with that as a whole.


I've been adopting the latter style for more tools where I just pass the entire map as --opts, e.g.:

$ echo '[1 2 3]' | puget --opts '{:print-color false}'


Another question: is the -X CLI parsing logic available as a library? I think this could be used in other places than clj as well (e.g. GraalVM compiled binaries).

Alex Miller (Clojure team)14:10:58

answering the last question first, no but that's something we're actively thinking about - I think it's something that could end up in Clojure itself (like clojure.main) but I am still actively changing the interface to it and will need further work before I think it's there

Alex Miller (Clojure team)14:10:18

on the former question, that's a good question, will think about it

Alex Miller (Clojure team)14:10:30

I mean really the idea was to put the base map in alias data and then just overrides on the cli, but some tools would benefit more than others from this


I keep thinking I've missed a way to have some kind of :deps-aliases in an alias to use the extra deps from another alias, similarly to how I can with :extra-paths.

Alex Miller (Clojure team)21:10:50

I'm confused by what you mean about :extra-paths

Alex Miller (Clojure team)21:10:37

unless you mean paths as alias data


I mean that I'm surprised there's no equivalent to :extra-paths [:build-paths] such as :extra-deps [:build-deps]. Obviously that syntax doesn't work, but that general idea.


I do yeah :)

Alex Miller (Clojure team)21:10:32

would certainly complicate the (already too complicated) merging logic


:extra-deps [:build-deps {…}] maybe…

Alex Miller (Clojure team)21:10:27

I'd probably be tempted to define something mappy instead so the merging would continue to work (like destructuring syntax or spec selects)


:extra-deps { [:build-deps] {}} ?

Alex Miller (Clojure team)21:10:27

well, I'm not going to design it right now :)

Alex Miller (Clojure team)21:10:41

if you wanted to file a jira or an ask request, would be glad to keep that idea around


I'll open a JIRA. :)