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...?

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

Apps should def declare

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 🙂

Which is effectively what happens

As top deps have priority

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 🙂

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'?

It’s both in this case I think

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.

There is a hidden verbose mode that sheds some additional light

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

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

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

hehe do I detect a tiny hint of revelation regret 😄

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.

perfect

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/1.9.0.381/deps.edn" :user "/Users/colin/.clojure/deps.edn" }

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?

still alpha!

No doubt.

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.

-Sdescribe2

I love it.

it's not a breaking change at all

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

: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