Happy to volunteer too!

the interesting bit is that parallelizing the jar downloads only got me so far because with Clojure artifacts, the pom is of significant size compared to the jar files and we end up downloading a lot more metadata during version selection

so, working through parallelizing the metadata download too, which is a lot harder to work into the algorithm

but, still seems doable

Very cool. Does maven do parallel at all?

yeah

I have parallel metadata during expansion working now

the benefits vary a lot depending on how much metadata/how much data/how much parallelism/how bushy the dep tree is, etc

for something like the luminus template, for lein to download the full dep tree is ~43 sec

clj before was 73 sec and is now 10 sec

that's kind of an extreme (lots of jars, huge fanout, lots of java, so big jars) etc

but 20-60% improvement is a common range

most of the time of course you're not really seeing those full numbers because you already have some or most of the libs downloaded in the cache

It seems that "RELEASE" and "LATEST" are not available in Maven 3, but tools.deps seem to support them. However, I cannot find any mention of these aliases in the documentation. What's the deal with them? Can people rely on them? Can developers safely recommend using them for e.g. such things as tools in the user's deps.edn? Also, I know that "RELEASE" is susceptible to cache issues - if no new dependency is needed to be retrieved during dependency resolution, the latest release available locally will be used (i.e., no check for a new release will be made) or something like that. Is "LATEST" also susceptible to such issues? Or does it reliably make a check for a new version each time the dependency resolution is done?

They are not supported and break the cache checking

That said, they do actually work and can be useful for one off calls in something like -Sdeps

I recommend using real versions instead

@thheller ^ FYI Yeah, I use "RELEASE" only for clj-kondo, tools.deps.graph, etc. Something that runs only to facilitate the development.

note that if you use RELEASE for tools, you generally won't get new versions of the tools after you first run them, unless you -Sforce (because the hashed key is just seeing "RELEASE" every time)

probably you're changing your local deps.edn or clj install frequently enough that you are periodically re-caching and don't notice this

it would be cool if tools.deps could resolve RELEASE in addition to tags maybe?

as in replace RELEASE with the most recent version in your deps.edn file

I'm not planning on adding any more mucking with deps.edn

but does not need to be in tools.deps - this itself could be a tool

I'm not sure that's actually the best solution though

https://github.com/Olical/depot does something similar, although I do not know if it processes "RELEASE" versions, but it updates the deps.edn in place definitely for deps that have versions.

Maybe it does Besides SNAPSHOT versions --resolve-virtual will also handle the special version strings "RELEASE" and "LATEST"

This script uses RELEASE to print the most recent versions of libraries that are newer than you current ones: https://github.com/borkdude/babashka/#list-outdated-maven-dependencies A bit of a hacky light version of depot (thanks seancorfield)

can i remove a dependency in an override?

@alexmiller: I vaguely remember you once mentioning a tools.deps top level keyword for tooling to use that wouldn’t pull in the main :deps? I can’t see any mention of it, so I’m guessing it’s not implemented yet?

you actually can remove a dependency with the classpath overrides

if you are in an alias, you can use :deps to replace instead of :extra-deps to add

ahh that was it, thanks.

@robert-stuttaford https://github.com/borkdude/babashka/issues/152

^ setting the classpath override to nil will remove it from the classpath

oh man thank you

only works in an alias I think

or you could have a server/clj alias so cljs alias doesn't inherit all the other deps as well

@borkdude's suggestion worked! :cljs {:classpath-overrides {com.datomic/datomic-pro nil}}