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 (80)
- # 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
but, still seems doable
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
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)
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?
Way down my list
I'll take that as a "no" then 🙂
probably you're changing your local deps.edn or clj install frequently enough that you are periodically re-caching and don't notice this
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?
iirc, no, but this has been on my radar for a while
I have datomic-pro overriding my tools.reader dep
looks like i'll have to use a cljs alias
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
that's been fixed in datomic-pro, but not sure if that's out yet
yeah that fix is in 0.9.6024
thanks, @alexmiller!
@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
ahh that was it, thanks.
oh man thank you
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}}