Fork me on GitHub
#tools-deps
<
2020-04-30
>
dominicm18:04:09

@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).

alexmiller18:04:12

it's coming...

alexmiller18:04:07

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

alexmiller18:04:21

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

alexmiller18:04:21

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

dominicm18:04:30

Ah, interesting. Didn't know that.

dominicm18:04:54

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

alexmiller18:04:22

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

dominicm18:04:58

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!

alexmiller18:04:00

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

alexmiller18:04:43

assuming you start with clj of course

dominicm18:04:49

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.