Clojurians Log v2

Is the 2.13.0 release going to be posted to Codeberg too? Or should I have the official Docker image builder download releases from GitHub for now?

for the general self-install we decided to keep it on github to avoid hammering volunteer-funded infrastructure https://codeberg.org/leiningen/leiningen/issues/4#issuecomment-11534818

typically most downstream packagers should have their own infrastructure with its own mirrors, but I guess docker is an exception here and just puts all the load on the upstream. so I don't think that should go to codeberg either.

honestly I am starting to question the whole idea of projects providing binary downloads at all for projecst that have packages in real package managers

ok, upon reflection I'm not sure I understand the implications here anyway. when you publish the docker image, you download the uberjar once, and the image contains the uberjar, so users of the image have it cached. and people making derivative images would also have it cached, right? under what circumstances would it get re-downloaded?

it would only be like ... if someone forked your image rather than publishing another image derived from it?

This is only run once per image variant (i.e. so a handful of pulls on a new lein release, new upstream image release for e.g. a new JDK version, etc.). All pulls from Docker Hub will pull the built image from them, not from you.

So a very small number of pulls from you

But I will point it back at GitHub

(In effect, this is a package manager packaging lein for its downstream users)

yeah, I'm getting my wires crossed with the github actions thing; my bad

but in general, normally a downstream packager would not use the prebuilt uberjar at all; packagers would pull down the tag, bootstrap it, run lein uberjar to produce the uberjar, and edit bin/lein-pkg to point at the uberjar created, rather than using the self-installed uberjar.

yeah, that's what I'm doing. I assumed the tag wasn't there since the release wasn't. but I see that it is, so all good 👍

well, to be more accurate, that's close to what we're doing. a lot of this was already there when I started maintaining so if you have feedback / suggestions on a better way to do it, I'd love to improve it: https://github.com/Quantisan/docker-clojure/blob/2029b9640c79eb05d187c67180aae9d9a70a8b69/target/debian-bookworm-26/lein/Dockerfile#L13 (ignore that vestigial comment about downloading the whole repo)

well, most packagers would build the uberjar from source instead of downloading it.

hard to say whether this script is downloading the uberjar just because it's easy, or if there's some other reason

Yeah. Docker is kind of weird in this regard in that we're "packaging" a whole ephemeral Linux system. So sometimes downloading binaries and verifying their checksums and signatures is preferred just for efficiency's sake. I'd have to go back and look if there's something that explicitly says to prefer doing it this way in the official images. I wouldn't be shocked if there were so that the Docker folks don't have a build farm recompiling sources all day haha

but like you said the building happens very rarely, so efficiency doesn't seem like much of a rationale there

yeah it's not a huge deal either way, but can get pretty busy across all updates to all official images. I'll look into it.