depstar

Discussion around https://github.com/seancorfield/depstar
tvaughan 2021-01-30T16:14:59.012100Z

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

seancorfield 2021-01-30T17:33:15.012800Z

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

seancorfield 2021-01-30T17:36:22.015900Z

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?

seancorfield 2021-01-30T17:39:38.016900Z

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

tvaughan 2021-01-30T21:05:09.023800Z

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

seancorfield 2021-01-30T21:07:45.024700Z

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.

seancorfield 2021-01-30T21:08:12.025200Z

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

seancorfield 2021-01-30T21:08:54.026200Z

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

tvaughan 2021-01-30T21:09:31.026700Z

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

seancorfield 2021-01-30T21:12:01.028100Z

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

tvaughan 2021-01-30T21:14:36.029700Z

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.

tvaughan 2021-01-30T21:15:02.030100Z

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

seancorfield 2021-01-30T21:16:04.031200Z

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.

tvaughan 2021-01-30T21:19:38.033200Z

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

seancorfield 2021-01-30T21:21:21.033800Z

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.

seancorfield 2021-01-30T21:22:50.034300Z

FYI, I have lots of different versions of the CLI installed so I can run tests across multiple versions:

seanc@DESKTOP-30ICA76:~/oss$ ls /home/linuxbrew/.linuxbrew/Cellar/clojure
clojure/            clojure@1.10.1.681/ clojure@1.10.1.745/ clojure@1.10.1.763/
clojure@1.10.1.590/ clojure@1.10.1.693/ clojure@1.10.1.749/ clojure@1.10.2.774/
clojure@1.10.1.672/ clojure@1.10.1.735/ clojure@1.10.1.754/

seancorfield 2021-01-30T21:24:07.035Z

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

tvaughan 2021-01-30T21:26:02.036500Z

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

seancorfield 2021-01-30T21:50:18.036800Z

Ouch! Good to know.

tvaughan 2021-01-30T22:33:14.040700Z

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

seancorfield 2021-01-30T22:41:02.041600Z

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

tvaughan 2021-01-30T22:50:15.044300Z

A thin jar is pushed to clojars

seancorfield 2021-01-30T22:50:52.045600Z

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

seancorfield 2021-01-30T22:52:08.046600Z

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 ๐Ÿ˜

tvaughan 2021-01-30T22:52:40.047100Z

You are in a maze of twisty little passages, all different ๐Ÿ™ƒ

seancorfield 2021-01-30T22:54:39.048400Z

That dates you (and me for recognizing it!) ๐Ÿ™‚

tvaughan 2021-01-30T23:01:49.048700Z

Gray beards unite!