Fork me on GitHub

Why does t.d.a have the org.clojure/clojure dep specified as provided?


That seems correct to me: it's always going to be run in a context that already has some version of Clojure loaded.


(shouldn't most Clojure projects assume Clojure is "provided"?)


The only exception IMHO is cljs self-host which would not require any dependency on clojure


> shouldn’t most Clojure projects assume Clojure is “provided”? Maybe, but none of them do.


It means that if I get the classpath for t.d.a from Maven or whatever, it won’t contain Clojure, which it clearly needs.


Yeah, I've tried to drum up support for a movement to change the Clojure dep to "provided" in projects but... inertia... 🙂


Thinking about it though, none of those libs work without Clojure so it really is a dependency for them.


It can be argued both ways. Clojure itself is kind of a weird "dependency" because in most projects, the choice of Clojure version comes first and then all the other dependencies are added. So, in that sense, Clojure is "provided". But, yeah, you can also argue Clojure "really is a dependency" -- but it's often going to be a different version for each of the other dependencies...?

Alex Miller (Clojure team)05:07:22

I think you have to separate app and lib contexts here too

Alex Miller (Clojure team)05:07:44

Apps should def declare

Alex Miller (Clojure team)05:07:27

Generally you don’t want your libs deciding the Clojure version of the context they’re used in


Yeah, I was kinda coming at this from the app p.o.v.: it chooses the Clojure version and the libs just deal with it 🙂

Alex Miller (Clojure team)05:07:00

Which is effectively what happens

Alex Miller (Clojure team)05:07:40

As top deps have priority

Alex Miller (Clojure team)05:07:03

So in app context, their choice is most important


Pretty much all the libs out there should use "provided" with Clojure and apps then drive it. But that doesn't seem to get much traction 🙂

Alex Miller (Clojure team)05:07:33

Yeah, I don’t think that’s a battle worth fighting


But t.d.a is an app, right?


I've only ever used it as a library...


The clj script invokes one of the -main functions in t.d.a. tho' (resolve tags, generate manifest, make classpath) but I'm not sure I'd consider tho' an app tho'?

Alex Miller (Clojure team)06:07:57

It’s both in this case I think

Alex Miller (Clojure team)06:07:23

But brew-install builds an uberjar so it’s really the app-maker


How are you guys debugging dependency conflicts?


clojure -Stree for a start @kenny


Doesn't show the decision made in selecting the dependency.


from what I've seen: the chosen dependency should only appear once in that tree, and its only parent is the driver of version selection


Correct. But I'd like to know the other parent dependencies that also have the conflicting child dependency.

Alex Miller (Clojure team)19:07:34

There is a hidden verbose mode that sheds some additional light

Alex Miller (Clojure team)19:07:31

clj -Sdeps ‘{:aliases {:v {:verbose true}}}' -A:v

Alex Miller (Clojure team)19:07:47

Likely to be confusing to some degree as it’s mostly designed to let me debug stuff right now

Alex Miller (Clojure team)19:07:36

I make zero promises about it’s existence or operation :)


hehe do I detect a tiny hint of revelation regret 😄

Alex Miller (Clojure team)20:07:05

Just making it clear that is a not even alpha feature :)


I think for that we have to drop down to the hebrew alphabet and call it an aleph feature


If we require people to do clj -א:v I’m pretty sure not many will find it.

😂 12

Several Cursive users have requested that Cursive show alongside the available aliases whether they’re system, user or project aliases. I can’t do that at the moment because there’s no way to tell which config file is which (short of something awful like guessing based on which is under the user’s home or something).


One thing that would fix that would be if -Sdescribe returned:

:config-files { :system "/usr/local/Cellar/clojure/" :user "/Users/colin/.clojure/deps.edn" }

👍 8

Any love for that idea?


Changing -Sdescribe at this point will break a bunch of other tooling that relies on the format of the (clojure-env) call I think?


Also, there's no reason that t.d.a. is limited to those three specific EDN files -- you can merge any number of EDN files to produce your environment...


I guess following Rich’s latest talk that should be :config-files2


You could put any number of keys in that map too.


it's not a breaking change at all


you cannot change :config-files but you could enrich the map

👍 4

:config-file-map 🙂


I ran into only being able to do -Sdeps once per invocation today


Hehe, or :config-file-type indexed the other way around, so the file path goes to a keyword describing its type.


this is related to the "how many config files are being merged?" question