Fork me on GitHub
Alex Miller (Clojure team)16:06:07

@borkdude picking up from other thread...

👍 1
Alex Miller (Clojure team)16:06:19

so the case is: root deps - has whatever clojure version user deps - has :deps {org.clojure/clojure {:mvn/version "1.10.3"}} tool deps - has :deps {org.clojure/clojure {:mvn/version "1.11.1"}}}


(afk for dinner, will be back)

Alex Miller (Clojure team)16:06:36

ah, so the tool's deps are not top level

Alex Miller (Clojure team)16:06:07

it will be {:deps {tool-lib tool-coord}}

Alex Miller (Clojure team)16:06:46

so anything defined top level in root/user deps.edn will be used over the tool


Are you explaining the status quo or actually how it's indented to work?

Alex Miller (Clojure team)16:06:54

don't remember if I've thought about this in the past (usually would only affect clojure version)

Alex Miller (Clojure team)16:06:24

and if you're on latest CLI, you'd be on latest clojure version


Didn't this come up in another thread here (or in #tools-build maybe?) a few weeks back?

Alex Miller (Clojure team)16:06:16

maybe? so many threads :)

Alex Miller (Clojure team)16:06:52

I did definitely consider both options back when this was implemented. don't remember if this aspect was considered or not, may have missed it.


I think that was around getting an "unexpected" version of Clojure because a project didn't specify a dependency (on Clojure) -- and then they got different Clojure versions with tools vs other stuff. So maybe not entirely related.


Oh yeah, that was it -- :default-deps not "working" for Clojure itself (due to different Clojure versions in CLI vs tool chain stuff).

Alex Miller (Clojure team)16:06:14

I don't really see this as an important issue - several things have to combine for it to surface as an actual problem for a user.


Which was the thread that started this discussion BTW? I think I must have missed that...


> several things have to combine for it to surface as an actual problem for a user. If a user has clojure 1.10.3 in their user deps, tools depending on 1.11 won't work, isn't that an important problem?


In general I think more specific settings should override global settings


-T will ignore user deps other than the specified alias and for an installed, named tool the user deps doesn't come into play.


@U04V70XH6 Well, they did come into play, which was why this discussion started


@U04V70XH6 Easy to repro: Put clojure 1.10.3 in your user deps.edn (top level) Then try:

clj -Ttools install io.github.babashka/http-server '{:git/tag "v0.1.4"}' :as serve


and then: clj -Tserve exec


This will fail. Then update user to 1.11 and it will work.

Alex Miller (Clojure team)17:06:25

"If a user has clojure 1.10.3 in their user deps" is a thing most people don't do, and even if they do, most tools do not require a newer version.

Alex Miller (Clojure team)17:06:40

I'm not saying this is not an issue, it just seems less important than many other things




Why would anyone put a version of Clojure itself in their user deps? That seems like a terrible idea.


Put aliases for different Clojure versions in user deps, sure, but not any top-level deps.


@U04V70XH6 Because the clojure CLI did not have 1.11 and I wanted a clojure 1.11 REPL everywhere? And I didn't expect those deps to override project-specific clojure versions since most tooling doesn't work that way. But I understand now that this doesn't work this way. TIL.


(and btw, I wasn't the one running into this problem, it was someone else, so apparently I'm not the only person doing terrible things)


clj -A:1.11 -- use an alias


And if a tool depends on a minimum version of Clojure, tell folks their CLI needs to "at least x.y.z.*" for it to work.


Folks need to be encouraged to keep their CLI install up-to-date 🙂


@U04V70XH6 This was before the clojure CLI was updated


CLI 1.11.. has been available for quite a while...


@U04V70XH6 I'm talking about why I added that thing there a while ago and then I of course forgot about it.

Alex Miller (Clojure team)17:06:51

if you can make an ask.clojure question, we can track votes/experiences


But it was @UK0810AQ2 running into this problem

Alex Miller (Clojure team)17:06:49

I would like to address this, just not at the top of my list (unless 10 people are having the same problem)


Clojure 1.11.1 was released on April 5th and the CLI was updated to that same day 🙂


@U04V70XH6 If you want all the details, I had org.clojure/clojure {:mvn/version "1.11.0-alpha4"} in there and updated with every alpha release ;)


This is actually a good way to force-test a new Clojure release in all your projects, now I see why it is like this :P


Anyway, thanks for clearing it up. Now I know what to tell people if they run into this problem.

Alex Miller (Clojure team)17:06:27

I don't think the fix for this is obvious, and it may interact with other possible dependency management like features

👍 1

If it happens more often (not sure what my threshold is) I'll create an ask issue


Made tool dependency (org.babashka/cli) compatible with 1.9 now which reduces the likelihood of giving problems.


@jr0cket The only catch with using a token is that you then force everyone to have a token handy. Setting up a key that has read-only access to the repos you're interested in is likely the best approach (but will likely require eating a new seat in your org)


I am confused now. I thought you were talking about GitHub actions. I don't understand the question anymore, sorry. I only use SSH keys if it's people on teams accessing repositories. Tokens are much more work for people, but useful for systems access.


I agree. I was only saying that with tools.deps you have to make a choice on which to use (or alternatively, go with different deps.edn files for different context, adapting dependency declarations as needed)


Ah wait sorry I replied to you but you weren't the one asking the question in the first place! sorry, I should have directed my comment to @U9MKYDN4Q