is the purpose of -Dclojure.libfile=... in the invocation at the end of the clojure bash (powershell) script diagnostic / for debugging?

I'm not seeing anything in the code at first glance that uses it so... I don't know... but it's a good question to ask Alex when he's around (Tuesday, probably, given that it's Labor Day weekend here) @sogaiu

@seancorfield tnx!

It’s to communicate for add-lib or tools like it

@alexmiller thanks for the explanation -- i presume it's not considered an api one can rely on (i.e. the ability to access the info via the clojure.libfile system property), is that right?

It has to be considered optional. The impl in add-lib knows how to use several means to detect the lib set, including classpath introspection

That whole thing is potentially something we may add to Clojure itself, tbd (which is why add-lib is not final)

I’d really like to use Deps as a lightweight way to manage deps for projects which aren’t always Clojure, or all Clojure. Currently there’s no way to globally exclude Clojure itself from the dependencies, correct?

As I understand it, in current Deps versions the system deps.edn is always read from the bundled copy in t.d.a, and there’s also no way to override that - is that correct?

I did try this in my deps.edn, but it didn’t work: {org.clojure/clojure {:mvn/version "1.10.1" :exclusions [org.clojure/clojure]}}

Would there be interest in a patch adding global exclusions support to deps, say using a top-level :exclusions key?

I also tried: {org.clojure/clojure {:local/root "empty"}} where empty/deps.edn is just {}, also no dice.

Global exclusions would be very useful for us too.

there is currently no way to "remove" a dependency from the top level, and clojure is included as a default dependency, so the practical effect is that clojure is always included

I don't consider this to be a major problem as the in-scope use case here is running Clojure programs (I don't consider clj to be a tool for generic deps mgmt)

that said, we do have a ticket for global exclusions and there certainly are times when that would be useful. similarly, it's pretty hard to use a different dep type (like local or git) to override the clojure version (due to issues in overrides of different dep type and version comparison), and that's something that I sometimes need to do

anyhow, I'm still thinking about the best solution to these

Another use case I have is running a Clojure fork.

Yeah, that’s unintentionally difficult as I discovered recently when I was trying to do something similar