This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-01-29
Channels
- # announcements (17)
- # aws (12)
- # babashka (27)
- # beginners (85)
- # bristol-clojurians (1)
- # calva (16)
- # cider (3)
- # clara (7)
- # clojure (85)
- # clojure-europe (13)
- # clojure-italy (19)
- # clojure-nl (2)
- # clojure-norway (6)
- # clojure-poland (1)
- # clojure-spec (31)
- # clojure-uk (61)
- # clojurescript (29)
- # core-async (10)
- # cursive (7)
- # data-science (1)
- # datomic (29)
- # docker (3)
- # fulcro (120)
- # graphql (16)
- # hugsql (2)
- # leiningen (17)
- # luminus (2)
- # off-topic (36)
- # other-languages (3)
- # pathom (13)
- # re-frame (12)
- # ring (2)
- # rum (1)
- # shadow-cljs (126)
- # tools-deps (56)
- # vscode (5)
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
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
that's kind of an extreme (lots of jars, huge fanout, lots of java, so big jars) etc
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?
That said, they do actually work and can be useful for one off calls in something like -Sdeps
@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)
Good to know. Explains some of the slightly odd behavior I thought I was seeing from time to time since my dot-clojure deps.edn
uses RELEASE a lot.
It would be nice if there was some way in deps.edn
to flag a dependency that should be rechecked periodically rather than cached indefinitely.
The issue is that the cache check is done in bash to avoid jvm load so the hash is purely text based
So there is no easy way to do what youโre suggesting without a lot of trade offs
Yeah, I think it would need an additional file in .cpcache
for "dependencies that should be rechecked" which is probably more complexity than anyone would want for the occasional use of this feature.
Is it worth me spending time thinking about this problem or would such a proposal not be considered anyway?
probably you're changing your local deps.edn or clj install frequently enough that you are periodically re-caching and don't notice this
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)
not exactly overriding. it contains a AOT compiled version of tools.reader which clojure will load instead of the actual tools.reader version on the classpath
@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?
if you are in an alias, you can use :deps to replace instead of :extra-deps to add
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}}