Andrew NesbittThe package manager in GitHub Actions might be the worst package manager in use today: https://nesbitt.io/2025/12/06/github-actions-package-manager.html
d@nny disc@ mc²@andrewnez cargo has such a vast degree of the problems you correctly assign to github actions and it is very specifically because any of the guarantees cargo provides for itself are completely unavailable to any build script. this means shared mutability retrofitted onto a subdir of ~/.cache and that is actually the best possible case. cargo specifically is the reason rustc remains so difficult to bootstrap because you absolutely 100% cannot send the output of one build script to another without shared mutable state
@andrewnez a lockfile is only as trustworthy as the things it had control over and with cargo that means checksums of source tarballs and even source checkouts aren't immutable. you absolutely can access the filesystem location cargo caches you in and use that as a release-specific mutable cache for your build script. no one has to know!
@andrewnez i think there's a slippage of terminology here too:
The core problem is the lack of a lockfile. Every other package manager figured this out decades ago: you declare loose constraints in a manifest, the resolver picks specific versions, and the lockfile records exactly what was chosen.
for one, the resolver is only as powerful as the constraints. if your constraints are limited to name and simple version matching, then a lockfile is indistinguishable from a manifest—we see this from pip freeze, which is actually quite notable for not being a lockfile.
@andrewnez python has per-platform and per-python-version constraints, for which you'll need something like pip install --report to get a "locked" experience. that feature was a generalization of my work here https://github.com/pantsbuild/pants/pull/8793 which was able to lazy-load python requirements upon execution.
the poetry package manager has a truly fascinating system where it resolves a dependency tree across several target platforms at once. it's able to do this though because python packaging protocols have had a lot of people caring about them for many years.
introduce --generate-ipex to (v1) python binary creation to lazy-load requirements by cosmicexplorer · Pull Request #8793 · pantsbuild/pants
Problem See pex-tool/pex#789 for a description of the issue, and https://docs.google.com/document/d/1B_g0Ofs8aQsJtrePPR1PCtSAKgBG1o59AhS_NwfFnbI/edit for a google doc with pros and cons of differen...
@andrewnez contrast to cargo. you can trivially change the checksum of an output by running rustup for a different toolchain. cargo does not have any mechanism to enforce this besides msrv. undocumented resolution semantics abound whenever a build script is involved because cargo offers no way to document those resolution mechanics. and cargo lockfiles are i believe the only thing secured by checksum, because everything else is invalidated by modification time.
@andrewnez i applied to NGI Zero for a way to rewrite cargo https://circumstances.run/@hipsterelectron/114610077000401178 but that was before i thought fixing build scripts was actually achievable. my first approach to this was to overlay the spack build graph onto cargo's by making use of—you guessed it—a shared cache dir. this is how https://docs.rs/re2 is able to specify dependency ranges for c++ code in a Cargo.toml.
d@nny disc@ mc² (@[email protected])
Content warning: ngi app on capillary the rust build tool
@andrewnez but one thing you need to completely redevelop from scratch in a cargo build script is ABI, because cargo always builds everything from source. spack on the other hand is able to resolve from-source and prebuilt packages because it has the most powerful constraint system https://spack.readthedocs.io/en/latest/spec_syntax.html, and it also distinguishes the spec hash of a package configured with the specified variants and platform from the output build hash.
@andrewnez there's a spectrum that goes from github actions to spack and cargo is much closer to the former than i'd like. i'm planning to write a tiny version of pants https://pantsbuild.org to replace cargo entirely in the rustc build system but the same tool should be able to make cargo build scripts much much more auditable if cargo continues to abdicate that responsibility for itself
