This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (3)
- # babashka (5)
- # beginners (68)
- # calva (34)
- # cider (6)
- # cljsrn (3)
- # clojure (48)
- # clojure-australia (2)
- # clojure-europe (1)
- # clojure-nl (4)
- # clojure-spec (28)
- # clojurescript (10)
- # conjure (20)
- # crux (8)
- # datahike (1)
- # deps-new (1)
- # depstar (27)
- # events (2)
- # fulcro (61)
- # graalvm (32)
- # membrane (18)
- # off-topic (20)
- # practicalli (10)
- # reagent (2)
- # shadow-cljs (8)
- # slack-help (20)
- # spacemacs (9)
- # sql (5)
- # vim (10)
I have a library, https://gitlab.com/tvaughan/kibit-runner, that I can compile to a native image with graalvm. I use depstar to produce the uberjar that is used in this process. Clojure 1.10.2 is required, and is the only version of Clojure that’s installed. However, strangely, I have to specify Clojure 1.10.2 in deps.edn or else the native compilation step barfs. Granted I haven’t done much to research why this is, but is there something about depstar that assumes Clojure 1.10.1 when none is specified in deps.edn, and ignores the currently installed version? pom.xml contains Clojure 1.10.2, FYI
depstar uses the computed project basis -- it doesn't "assume" any version of Clojure @tvaughan
depstar itself obviously needs a version of Clojure present to run, but that needn't be the same as the version included in the uberjar. Per the Classpath section of the README, it will use the system and project
deps.edn by default to compute the classpath -- omitting the user
deps.edn in line with the
-Srepro option on
clojure intended for repeatability. If you're relying on your user
deps.edn specifying the version of Clojure in use, that's convenient for you but not good for repeatability. However, you could tell
depstar to consider your user
deps.edn by specifying
:repro false in your
depstar invocation. Does that answer your question?
(just checked and
depstar requires Clojure 1.9 or later to run -- but that has nothing to do with the version of Clojure that will be added to the JAR file, which will be determined by the computed classpath per the docs)
> Does that answer your question? There is no user deps.edn involved in this case. There is only a project deps.edn. I was hoping I wouldn't have to specify a Clojure version in the project deps.edn. I'm curious about why when there is no Clojure version specified in the project deps.edn, but there is in pom.xml and 1.10.2 is the only version installed, things seem to go awry. Or is this bad practice and I should always specify an explicit Clojure version in the project deps.edn when creating an uberjar?
If you don't specify an explicit Clojure version in the project
deps.edn file, you'll get whatever is the default provided by the CLI itself and that will change over time as new CLI versions are released.
The very latest CLI defaults to 1.10.2 now. Prior versions have used 1.10.1 for quite a while.
See https://clojure.org/releases/tools -- which doesn't go back further than the 1.10.1.x release series.
If you want a specific Clojure version in your uberjar, you should specify it in your project
deps.edn, otherwise you're reliant on whatever default the CLI provides (so you'll get different results building the uberjar with different CLI installs on different machines).
Alright. I'll do that. In this particular case everything is built in a container. The Clojure version is tightly controlled, and should always be deterministic.
It's worth being specific about whether you mean "Clojure CLI" version or the "Clojure language" version. They are not directly connected. The most recent CLI can be used with any language version all the way back to 1.0.0.
Understood. I'm assuming that installing 184.108.40.2064 (https://clojure.org/guides/getting_started#_installation_on_linux) installs the latest Clojure CLI which should default to 1.10.2 (per an announcement in #tools-deps IIRC). This is probably where I've gone wrong
It will default to 1.10.2 if not overridden by something in the user
deps.edn file or the project
deps.edn files, yes.
FYI, I have lots of different versions of the CLI installed so I can run tests across multiple versions:
[email protected]:~/oss$ ls /home/linuxbrew/.linuxbrew/Cellar/clojure clojure/ [email protected]/ [email protected]/ [email protected]/ [email protected]/ [email protected]/ [email protected]/ [email protected]/ [email protected]/ [email protected]/ [email protected]/
clojure/ version happens to be 220.127.116.114 installed when that was the latest stable but I'm actually using 18.104.22.1684 as my default now)
Right. I went in the opposite direction. The native image compilation only works with 1.10.2. I created a container with this version only to avoid any possible mixup
Yeah, and since this is pushed up to clojars and used by others (it’s included in practicalli/clojure-deps-edn) I want to avoid hard-coding 1.10.2 in deps.edn. Of course I could use an alias. I just thought this could be avoided by selecting the right build environment as pom.xml is created at build time. But as they say, explicit is better than implicit :)
It's unusual to publish an uber JAR to Clojars. Am I misunderstanding what you're saying?
Ah, good. I was just reading the Kibit issue about running it via
deps.edn... It's all beginning to make more sense now 🙂
Leiningen's plugin architecture had a tendency to create tooling that was very tied into Leiningen and was often hard to reuse as libraries in other contexts 😐