@alexmiller I know it's been discussed before, but one good reason to have access to the resulting deps.edn that built the current JVM is for file watching. I want to automatically configure figwheel to watch my :paths and my :local/root deps, but not my gitlibs (which are dirs on the classpath). Workaround is to filter anything containing ".gitlibs", but I'm not sure of the portability or future-proof of that (as soon as someone needs a config flag for that, the tower falls).

it's coming...

that work is done and in a branch but ties into ongoing work on add-lib and tools.build and maybe even some clojure core stuff

the new term we're using for this is the "runtime basis", which is a superset of the merged deps.edn that also includes your effective alias mods, the lib map and a (datafied) classpath. clj will compute this, cache the basis file, and inject a reference to it via a system property. we've got some additional apis to read and help you use the basis that may end up in clojure proper (the reading part does not depend on tools.deps - it's just data), but those are really just helpful, it's just reading edn and using clojure data

fyi, there is an env var that defines the gitlibs root, so you could base it on that (GITLIBS)

Ah, interesting. Didn't know that.

https://github.com/clojure/tools.gitlibs#cache-directory

I've also just realized that the libfile is sufficient. I can figure out the intersection of classpath dirs & gitlibs from that.

so, that is currently being injected by clj as I describe above, but that's probably going to be replaced

I've spent a lot of time this afternoon due to a collision of me trying to remove code that filtered libs out (but indirectly - so I didn't know that was the difference) & a bug figwheel where it can't load certain namespaces that are in watch dirs, and it's caused by a particular dependency we have... and now it's almost 20:00!

there is a system property clojure.libfile that points to the libfile used to start the current process

assuming you start with clj of course

Hmm, okay. I'll probably make sure my code explicitly removes the bad dependency then, that way it'll continue working after the clj version bump.