Clojurians Log v2

Even on a rolling release?

Don’t know what that is. But if it uses the “package” version you cannot use the handy upgrade/downgrade feature of lein itself. And that’s what is occasionally useful

rolling release = a distro that just gets package updates continuously, not twice a year or whatever

The Leiningen upgrade/downgrade, if installed via Leiningen's own methods vs. some Linux distribution's package manager, seems to me to work regardless of that distribution's package update policies. There is no need to rely on, or wait for, anyone else to create a package for newer (or older) versions of Leiningen. I agree it isn't "just like every other package" you tend to install, but it is about as flexible as you can get, if you care which version you are running. I think I've typically got about 10 versions of Lein installed on my system at any given moment, which takes only a few KBytes of disk space the way it is packaged, since it is only a small shell script. Only the larger JAR files of the Lein versions I've actually used on the system get downloaded.

Sounds a bit like me with the Clojure CLI:

seanc@DESKTOP-30ICA76:~/oss$ ls -d /home/linuxbrew/.linuxbrew/Cellar/clojure*
/home/linuxbrew/.linuxbrew/Cellar/clojure             /home/linuxbrew/.linuxbrew/Cellar/clojure@1.10.1.763
/home/linuxbrew/.linuxbrew/Cellar/clojure@1.10.1.590  /home/linuxbrew/.linuxbrew/Cellar/clojure@1.10.2.774
/home/linuxbrew/.linuxbrew/Cellar/clojure@1.10.1.672  /home/linuxbrew/.linuxbrew/Cellar/clojure@1.10.2.790
/home/linuxbrew/.linuxbrew/Cellar/clojure@1.10.1.681  /home/linuxbrew/.linuxbrew/Cellar/clojure@1.10.2.801
/home/linuxbrew/.linuxbrew/Cellar/clojure@1.10.1.693  /home/linuxbrew/.linuxbrew/Cellar/clojure@1.10.3.810
/home/linuxbrew/.linuxbrew/Cellar/clojure@1.10.1.735  /home/linuxbrew/.linuxbrew/Cellar/clojure@1.10.3.814
/home/linuxbrew/.linuxbrew/Cellar/clojure@1.10.1.745  /home/linuxbrew/.linuxbrew/Cellar/clojure@1.10.3.822
/home/linuxbrew/.linuxbrew/Cellar/clojure@1.10.1.749  /home/linuxbrew/.linuxbrew/Cellar/clojure@1.10.3.839
/home/linuxbrew/.linuxbrew/Cellar/clojure@1.10.1.754

(! 503)-> ls -d /usr/local/Cellar/clojure*
/usr/local/Cellar/clojure               /usr/local/Cellar/clojure@1.10.1.716    /usr/local/Cellar/clojure@1.10.2.801
/usr/local/Cellar/clojure@1.10.1.561    /usr/local/Cellar/clojure@1.10.1.723    /usr/local/Cellar/clojure@1.10.2.805
/usr/local/Cellar/clojure@1.10.1.590    /usr/local/Cellar/clojure@1.10.1.727    /usr/local/Cellar/clojure@1.10.3.810
/usr/local/Cellar/clojure@1.10.1.596    /usr/local/Cellar/clojure@1.10.1.735    /usr/local/Cellar/clojure@1.10.3.814
/usr/local/Cellar/clojure@1.10.1.619    /usr/local/Cellar/clojure@1.10.1.739    /usr/local/Cellar/clojure@1.10.3.822
/usr/local/Cellar/clojure@1.10.1.636    /usr/local/Cellar/clojure@1.10.1.745    /usr/local/Cellar/clojure@1.10.3.829
/usr/local/Cellar/clojure@1.10.1.641    /usr/local/Cellar/clojure@1.10.1.749    /usr/local/Cellar/clojure@1.10.3.833
/usr/local/Cellar/clojure@1.10.1.645    /usr/local/Cellar/clojure@1.10.1.754    /usr/local/Cellar/clojure@1.10.3.839
/usr/local/Cellar/clojure@1.10.1.672    /usr/local/Cellar/clojure@1.10.1.763    /usr/local/Cellar/clojure@1.10.3.849
/usr/local/Cellar/clojure@1.10.1.681    /usr/local/Cellar/clojure@1.10.2.774    /usr/local/Cellar/clojure@1.10.3.875
/usr/local/Cellar/clojure@1.10.1.693    /usr/local/Cellar/clojure@1.10.2.781    /usr/local/Cellar/clojure@1.10.3.882
/usr/local/Cellar/clojure@1.10.1.697    /usr/local/Cellar/clojure@1.10.2.790
/usr/local/Cellar/clojure@1.10.1.708    /usr/local/Cellar/clojure@1.10.2.796

What Java do people use to run CJ/CLJS projects? I was confused about the JVM implementations, but I understand that OpenJDK is actually the original thing from Sun/Oracle? What version is recommended? Always the newest one? I can see there are many openjdk-* packages in Ubuntu. (I installed openjdk-16-jre-headless for now.)

empty collections are truthy in clojure. does that mean folks are more likely to have a function return either a non-empty collection or a nil? as opposed to staying within a narrower type and always returning a collection (of a given type), whether empty or not

quite common to call seq on collections as return values to probe this. Often return a collection and let the caller care about whether it has any values in it

not-empty is handy in such cases. Let the particular contexts handle it the way they want than deciding truthiness or falsiness beforehand

that seems consistent with what i perceive to be a general preference for avoiding nil in clojure

thanks! i greatly prefer not-empty over seq

OpenJDK is the open source GPL core, Oracle releases it's own derived from that + some extra stuff plugged in

most of the variants are built from the same OpenJDK core, except for the IBM j9 vm, which is a different impl

there are both "LTS" (long term support) versions and intermediate releases without that. With Clojure, we recommend using an LTS version if you don't specifically need something from a newer version. The last 2 LTS versions were 8 and 11. 17 will be coming out this fall and will be the next LTS version.

i don't think there's a general preference for avoiding nil. but that gets close to style and personal preference

So we would currently recommend 11 (but other versions work too, including 16)

I would actually recommend using the jdk (development kit) though, not the jre (runtime engine), as it includes tools you will find useful.

oh, that's interesting. what about place oriented programming and all that? {:a nil} vs {}?

i thought for sure the language convention was to omit a value instead of saying explicitly "this value is absent" via a nil

generally true to not put nil values in a map. I was just talking about shying away from nil as a value in general.

Thank you @alexmiller. So to be clear, when you say LTS, you are referring to LTS version of OpenJDK? Which in Ubuntu would then be openjdk-11-jdk-headless I reckon?

Yep

Perfect :thumbsup: Cheers!!!

All non-LTS versions should basically be considered dead (except the latest), so I would NOT use 9-10, 12-15

in what namespace do y’all put your integration tests? I was just going to go with test/<package>/integrations/, but wondering if any tools look for something standard

I don’t there’s any particular convention for that, TBH.