Nevermind, Slackbot answered!

@logbot @pavlos @seancorfield: Answer to <https://clojurians-log.clojureverse.org/tools-deps/2022-01-15/1642213393.070600> (‘I'm curious about the process for upgrading stuff?’): In the ideal case, all you have to do is: checkout the guix repository, compile it, run "./pre-inst-env guix refresh -u the-package-that-you-want-to-update"

In the ideal case, that ‘just works (TM)’, but it unfortunately doesn't work for all packages, e.g. it used to not work for minetest mods. It should, however, work for all pypi packages. I don't know how well it works for Clojure, but it should work for everything that has a git repository as source code and tags versions.

‘It seems like packaging clojure-tools relies on community volunteers and that means they have to repackage every time there's a new release of the CLI?’ (https://clojurians-log.clojureverse.org/tools-deps/2022-01-15/1642213393.070600): It does not have to be repackaged --- assuming no complications (new dependencies etc.), all that's necessary is modifying the 'version' field and 'sha256' field of the package definition; the old package definition can be reused, it only has to be tweaked a bit.

Additionally, it is not necessary to always update the package definition after an update. You only have to update it if you need the the new version of the CLI.

I.e., I expect that most of the time, for most users, a slightly out-of-date version of the CLI will probably go unnoticed

‘What happens if a community volunteer moves on, or even is off on vacation for a while? Doesn't that just block people from upgrading their clojure-tools in a timely manner?’

‘It's like these package managers are stuck in the 1990s before the Java ecosystem appeared...’

‘What I like about brew on Linux is that I can install any version of the Clojure CLI, as soon as it is released by the core team -- and I can install prerelease versions just as easily as stable versions, and I can switch back and forth between them easily.’

Some more general stuff on ‘why use package managers like Guix or Debian’: security! What if an upstream turns out to be malicious and put malware in the binaries (which is virtually undetectable if done properly until it's too late) or the source code (see NPM compromise)? What if upstream lists an old version of a package among its dependencies, and it turns out to have a vulnerability (log4j) -- in a package manager like Guix and Debian, Guix and Debian can easily fix the vulnerability without having to modify anything in the upstreams.

The upstream code might be broken, and needs to be patched in Guix! E.g., the upstream code might try to run "/bin/ls", even though "/bin/ls" does not exist in Guix and needs to be replaced with an appropriate "/gnu/store/.../bin/ls" filename.

What if an user wants to install an application that depends on both Clojure libraries (which are on Maven) and Python libraries (which are on pypi)? If the user were told to use the Clojure tools and pypi, then it seems to me that that would be very very cumbersome, wouldn't a simple apt-get install some-app or apt-get install some-app be better?

‘This is all basically same as Debian, that redoes all this same work with their own slightly different build system that makes slightly different versions of libs too. They chunk it up into periodic release trains’ --> Guix doesn't do periodic releases (technically, some commits are tagged with some version number, but that's more of a milestone for blog posts etc.), just do "guix pulll" to get the latest version of guix. Also, the build system is completely different from Debian.

Hi, Nix user here 🙂 Thanks a lot for taking the time to write all of this out, I very much agree!

For those reading along: Nix and Guix share a lot of design philosophy, so most of these points apply to both

Here's another, very practical reason we're trying to move our builds to a pure build system: Upstreams like Maven central or clojars have rate limits, and if you're not very careful, it's very easy to run into these if you run a lot of builds in CI/CD. We have a cache system set up for .m2, but it's quite delicate and it broke again recently, leaving us with many pipeline failures due to rate limit errors.

Running your own Maven repo to mirror upstream is an idea, but it's very bothersome and stateful. Serving a Nix or Guix store is comparatively easy (it's just a bunch of immutable files!) and it's not specific to the Java ecosystem - you can use it for all kinds of builds!