:main-opts ["-m" "hf.depstar.jar" "yang.jar" "--exclude" "clojure/core/specs/alpha.*"]}
756 Mon Aug 24 20:21:36 EDT 2020 yang/java$map__GT_edn$iter__130__134.class
3064 Mon Aug 24 20:21:36 EDT 2020 yang/java__init.class
1316 Mon Aug 24 20:21:36 EDT 2020 yang/java$fn__128.class
2003 Mon Aug 24 20:21:36 EDT 2020 yang/java$map__GT_edn$iter__130__134$fn__135$fn__136.class
0 Mon Aug 24 20:23:37 EDT 2020 clojure/
0 Mon Aug 24 20:23:37 EDT 2020 clojure/core/
0 Mon Aug 24 20:23:37 EDT 2020 clojure/core/specs/
0 Mon Aug 24 20:23:37 EDT 2020 tolitius/
1867 Mon Aug 24 20:21:36 EDT 2020 tolitius/Yang.class
yep, it works )Cool, thanks for testing!
Can I specify version ranges in deps.edn for dependencies?
no
@janne.sauvala Yes, you can, but you shouldn't. The string used for the version in :mvn/version
is just passed through to the underlying library, e.g.,
(! 1176)-> clj -Sdeps '{:deps {hiccup {:mvn/version "(,1)"}}}'
DEPRECATED: Libs must be qualified, change hiccup => hiccup/hiccup
Downloading: hiccup/hiccup/1.0.0-SNAPSHOT/maven-metadata.xml from clojars
Downloading: hiccup/hiccup/1.0.0-SNAPSHOT/hiccup-1.0.0-20120218.070543-1.pom from clojars
Downloading: hiccup/hiccup/1.0.0-SNAPSHOT/hiccup-1.0.0-20120218.070543-1.jar from clojars
Clojure 1.10.1
user=>
Current version is 1.0.5 but you can get the highest version below that
(! 1177)-> clj -Sdeps '{:deps {hiccup {:mvn/version "(,1.0.5)"}}}'
DEPRECATED: Libs must be qualified, change hiccup => hiccup/hiccup
Downloading: hiccup/hiccup/maven-metadata.xml from clojars
Downloading: hiccup/hiccup/1.0.4/hiccup-1.0.4.pom from clojars
Downloading: hiccup/hiccup/1.0.4/hiccup-1.0.4.jar from clojars
Clojure 1.10.1
user=>
But version ranges are "Bad(tm)" and should be avoided.^ @vlaaad FYI
it's not actually passed through, it's resolved in canonicalization to the max in range
but a) version ranges have many known weirdnesses and b) as a non-specific version, they also break clj's caching (you will retain the same cached classpath even if newer versions become available)
Interesting to see it works, thanks @seancorfield! I realized I haven’t seen anyone using version ranges so I was wondering were those intentionally not supported
they are officially not supported
but unofficially handled because they exist in the wild, particularly with transitive deps
@alexmiller Good to know re: canonicalization -- I passed in a bad range and the exception came from Aether so I assumed it was just being passed through. My bad:
Unbounded version range (1,
org.eclipse.aether.resolution.VersionRangeResolutionException: Failed to resolve version range for hiccup:hiccup:jar:(1,: Unbounded version range (1,
at org.apache.maven.repository.internal.DefaultVersionRangeResolver.resolveVersionRange(DefaultVersionRangeResolver.java:137)
at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveVersionRange(DefaultRepositorySystem.java:247)
> I haven’t seen anyone using version ranges Because they're bad and folks avoid them 🙂
well the resolution happens via aether
I think if you had more of stack, you'd probably see canonicalize in there somewhere
Yes. Too bad I have seen them used quite a lot in npm and python world. It is good that bad practice hasn’t polluted clojure community 🙂