pull down to refresh

Oh, huh. I guess that makes sense? I don't quite know how these package managers work. I thought you download it once and now you have a copy on your machine. You only need to redownload if upgrading to a new version

124 sats \ 0 replies \ @rblb 2 Mar

They do, but these are likely CI builds. These builds run on containers/vms spawned from scratch for each commit, they build, validate, publish (if a release) and then self destroy.

It is a good way to avoid any possible cross contamination between builds for security and reproducibility.

Caching here, without compromises, can be quite complex depending on the underlying system, and might require a custom build script for CI, that is often undesirable, because ideally the CI build should follow the same path as a manual build whenever possible, so it can also catch bugs in the build script itself.

The people complaining about this are the hosts of Maven Central (Java's npm), and they caused this themselves by pushing for Java build centralization. You can configure a project to use any Maven repository in Java, but it is so inconvenient and looks so suspicious or hard to verify that everyone ended up publishing to Maven Central, going through all the annoying hoops they put in place. Somehow they did not consider that they would have to host the entire world?

I think we need a nostr alternative: metadata signed and curated on nostr, payloads hosted on the dev own servers.

reply
69 sats \ 3 replies \ @k00b 2 Mar

They probably aren't using a package manager, or at least one that persists between builds, because package managers cache.

reply

I see. Custom build script then? Coz I thought even amateurs just use package managers most of the time like npm and pip

reply
168 sats \ 1 reply \ @k00b 2 Mar

Yep custom and these build systems often don't persist the package manager's cache - preferring to start from a blank slate.

reply

This is also because actions/cache invalidation is hard to do right, though from a dependency caching perspective it works well once you have figured out what to monitor. Your LLM will not think of this out of the box.

For packages, apt-cacher-ng works well, but... unfortunately I need to figure that out for alpine apk too. Centralized docker image caching would be good to have too (because right now it only caches on my actions runner instance, which is inefficient for me too, because I'm storing everything 3x)

The real challenge for me has historically been golang, but since 1.25 I should be able to get something going there. Just need to prioritize solving this.

reply