Fork me on GitHub
#depstar
<
2021-01-30
>
tvaughan16:01:59

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

seancorfield17:01:15

depstar uses the computed project basis -- it doesn't "assume" any version of Clojure @tvaughan

seancorfield17:01:22

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?

seancorfield17:01:38

(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)

tvaughan21:01:09

> 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?

seancorfield21:01:45

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.

seancorfield21:01:12

The very latest CLI defaults to 1.10.2 now. Prior versions have used 1.10.1 for quite a while.

seancorfield21:01:54

See https://clojure.org/releases/tools -- which doesn't go back further than the 1.10.1.x release series.

tvaughan21:01:31

This is what I assumed. 1.10.2 is the only version that's installed.

seancorfield21:01:01

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).

tvaughan21:01:36

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.

tvaughan21:01:02

Thanks a lot for taking the time to walk me through this @seancorfield

seancorfield21:01:04

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.

tvaughan21:01:38

Understood. I'm assuming that installing 1.10.2.774 (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

seancorfield21:01:21

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.

seancorfield21:01:50

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]/

seancorfield21:01:07

(that clojure/ version happens to be 1.10.1.754 installed when that was the latest stable but I'm actually using 1.10.2.774 as my default now)

tvaughan21:01:02

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

seancorfield21:01:18

Ouch! Good to know.

tvaughan22:01:14

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 :)

seancorfield22:01:02

It's unusual to publish an uber JAR to Clojars. Am I misunderstanding what you're saying?

tvaughan22:01:15

A thin jar is pushed to clojars

seancorfield22:01:52

Ah, good. I was just reading the Kibit issue about running it via deps.edn... It's all beginning to make more sense now 🙂

seancorfield22:01:08

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 😐

tvaughan22:01:40

You are in a maze of twisty little passages, all different 🙃

seancorfield22:01:39

That dates you (and me for recognizing it!) 🙂

tvaughan23:01:49

Gray beards unite!