3 ms·
I think Nix does/comes close to what you're after. Nix 'packages' are just text files describing the build/install process, so they can be version controlled (
by chriswarbo 10y ago
I think Nix does/comes close to what you're after.
Nix 'packages' are just text files describing the build/install process, so they can be version controlled (e.g. there's a big repo at https://github.com/nixos/nixpkgs https://github.com/nixos/nixpkgs ).
Dependencies, build environments, etc. are fully specified by the package and isolated from each other, and there is an emphasis on reproducibility, so building/installing a particular package should always give the same results. (This isn't enforced, but a non-reproducible package is considered buggy, and there are tools to check if a package can be reproduced)
Nix packages themselves can reference external dependencies, like git repos and URLs, and usually provide a fixed checksum to compare the output against; if it doesn't match, the build is aborted. Wrappers/translators are also available to integrate with other package manager ecosystems, e.g. cabal/hackage for Haskell packages.
Results are cached locally (packages are only built once, until they get garbage collected) and remotely (if a build server has already built a package, you can fetch it from there instead).
For development environments, you can write a Nix package for your project then run the 'nix-shell' command to enter its build environment (i.e. all dependencies available, environment variables set, etc.)
- TickleSteve 10y ago...similar to spack... Isn't this effectively equivalent to version-controlling a shell script that contains a set of 'curls' or 'clones'? What I had in mind would be more invisible and self-contained within the VCS. It would effectively be a meta-VCS.