Fork me on GitHub

Hi, I’m not sure if this is the most suitable channel but I’m trying to figure out the differences between clj -T:something and clj -Tsomething. They seem to give different output:

$ clj -Ttools list
TOOL   LIB                            TYPE  VERSION
tools  io.github.clojure/  :git  v0.2.2

$ clj -T:tools list
Unqualified function can't be resolved: list
Could anyone give me a hint? Thanks!

Alex Miller (Clojure team)04:11:54

you came to the right place, and yes they are different

Alex Miller (Clojure team)04:11:26

-T:something says to use the alias :something in your deps.edn -Tsomething says to use the installed tool named something

Alex Miller (Clojure team)04:11:45

both will remove your project deps/paths and add :paths ["."]

Alex Miller (Clojure team)04:11:40

in the case above, tools is the name of a pre-installed tool (you can find the guts of it at ~/.clojure/tools/tools.edn - which is really just a lib/coord that will be added to your deps)

Alex Miller (Clojure team)04:11:57

:tools is nothing, which is why it errors


Thanks for the info! So tools in -Ttools is the name of a built-in, and deps in -X:deps is the alias of a built-in. I see how I got confused.


I notice that running clj -Mantq and clj -M:antq work, is the first form wrong?


I think the : is just omitted in the first form…

Alex Miller (Clojure team)14:11:08

the former is (sloppily) allowed

Alex Miller (Clojure team)14:11:42

really just a by-product of how the parsing is implemented


wasn't the first one the default syntax in the very beginning and eventually -A:foo:bar became the standard? By the time -M came it was an established idiom?

Alex Miller (Clojure team)14:11:41

no, the first one has never been a documented thing

Alex Miller (Clojure team)14:11:56

it has always been concatenated keywords


ah I see :)

Jeff Evans20:11:20

Anyone know what might be causing this? When running clojure -X:deps prep

clojure --help | grep Version
Prepping metabase/java-deps in /Users/<person>/repos/metabase_master/java
Error compiling Java sources: nil
 [{:type java.lang.NullPointerException,
 [[$javac invokeStatic "javac.clj" 28]
  [$javac invoke "javac.clj" 21]
  [clojure.lang.Var invoke "" 384]
  [$javac invokeStatic "api.clj" 229]


@jeffrey.wayne.evans What do you get when you evaluate



So this is what causes the NullPointer exception.

😁 1

I have no idea why it returns nil in your case, but I'm not that familiar with the API to be honest


Perhaps you are using an JRE as opposed to a JDK?

Alex Miller (Clojure team)21:11:30

JRE would be my guess too

Jeff Evans21:11:06

thanks, folks. this is for a colleague who is just trying to iterate without becoming an expert in Clojure, so I’ll double check to ensure the environment is completely sane. I think we had some recent confusion around the whole Temurin project switchover stuff

Jeff Evans00:12:35

To close the loop, that is indeed what the issue was (JRE as opposed to JDK)

Alex Miller (Clojure team)00:12:22

Probably something that can be better reported


I see this on every Circle run for a Tools-based job. Is there a recommended way to cache it? Using circleci/clojure:openjdk-17-tools-deps-buster-node btw.

Alex Miller (Clojure team)21:11:33

it's a bug in the clojure action

Alex Miller (Clojure team)21:11:39

I think there's an issue for it

Alex Miller (Clojure team)21:11:48

at least I assume that's the same cause


does the Circle image use setup-clojure?


(although that doesn't help with the caching option, it could at least get it into your cachable folder if you then ran clojure -P ... afterward)


not sure if the GH Actions and Circle thingies are the same issue, although if you're sure I'll take your word about it from my side other than the lack of caching I'm not experiencing an issue in Circle


Are you caching ~/.gitlibs?


Sorry, I sort of assumed you already would be...


(I've stopped using CircleCI at this point)


> Are you caching `~/.gitlibs`? yes but /.clojure /.cpcache seem needed as well, thanks!


Ah, yes, otherwise it will want to recompute dependencies.


(make sure you're on a non-XDG system -- on XDG systems, it's ~/.config/clojure not ~/.clojure)


I mention that because the nvd-clojure integration test seems to be on an XDG system -- note the path for tool/tools.edn -- so ~/.clojure wouldn't help you there.

👍 1

No, CircleCI doesn't use setup-clojure - that one is specific for Github Actions (as always: I reserve the right to be wrong)


Good to know but caching ~/.gitlibs and ~/.clojure is the important part, right? Even for CircleCI.


@seancorfield don't you need to cache $PWD/.cpcache as well as the clojure CLI writes cp caches there too? Or does setup-clojure behave otherwise?


True, you could cache that to avoid recomputes for the classpath for running tests, which would speed up repeated runs where the classpath hasn't changed. And it's probably not worth caching ~/.cpcache to be honest. My main concern was preventing unnecessary git checkouts and Maven/Clojars downloads.


I'm not entirely sure what $PWD would be for GH Actions. I think ~ is /home/runner and I think $PWD might be /home/runner/work/<repo>/<repo> based on some of what I'm seeing in the logs but I haven't confirmed that... Not sure if how to specify that in the cache action without hard-coding the path, per repo tho'?