This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-06-24
Channels
- # announcements (39)
- # aws (4)
- # babashka (18)
- # beginners (32)
- # biff (10)
- # calva (22)
- # clj-kondo (11)
- # clj-on-windows (2)
- # cljs-dev (20)
- # clojure (31)
- # clojure-europe (130)
- # clojure-norway (21)
- # clojure-spec (24)
- # clojure-uk (17)
- # clojured (2)
- # clojurescript (6)
- # conjure (1)
- # core-async (5)
- # cursive (11)
- # datalevin (1)
- # datomic (9)
- # emacs (24)
- # figwheel-main (42)
- # fulcro (6)
- # gratitude (6)
- # honeysql (8)
- # juxt (16)
- # kaocha (6)
- # lsp (235)
- # malli (2)
- # nbb (7)
- # off-topic (23)
- # other-languages (24)
- # pedestal (7)
- # reitit (6)
- # sci (1)
- # shadow-cljs (21)
- # tools-build (22)
- # tools-deps (57)
- # vim (24)
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"}}}
ah, so the tool's deps are not top level
it will be {:deps {tool-lib tool-coord}}
so anything defined top level in root/user deps.edn will be used over the tool
status quo
don't remember if I've thought about this in the past (usually would only affect clojure version)
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?
maybe? so many threads :)
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 it is this thread: https://clojurians.slack.com/archives/C02B5GHQWP4/p1651524280682919
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).
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...
In announcements
> 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?
-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
"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.
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.
if you can make an ask.clojure question, we can track votes/experiences
But it was @UK0810AQ2 running into this problem
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 1.11.1.1105 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.
I don't think the fix for this is obvious, and it may interact with other possible dependency management like features
Made tool dependency (org.babashka/cli) compatible with 1.9 now which reduces the likelihood of giving problems.
Just FYI, I came across one user who added deps in their user deps.edn here: https://clojurians.slack.com/archives/CHY97NXE2/p1665059013827909?thread_ts=1665055904.775729&cid=CHY97NXE2
@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