As a developer, I would rather prefer to have a general purpose package manager, which provides reproducible environments and is compatible with existing repos, than yet another language specific package manager. Nix example above is a good suggestion, although Nix has a messy implementation. Is it possible to make a PM, which is compatible with Nix repos, but without all Nix shortcomings?
There are three important ideas that the Go team discovered in building the Go package management system that are worth stealing:
- tree dependencies (no circular imports) avoid exponential compilation times.
- Minimum Version Selection (MVS) instead of latest/SAT solving keeps package dependency resolution fast rather than exponential, while keeping builds predictable, high-fidelity, and stable.
- Supporting two different major versions of the same package is required for long term stability in the face of two package authors creating a diamond dependency graph and then having one arm upgrade independently of the other arm.
These are discussed in Russ Coxâs classic posts research!rsc: Go += Package Versioning (Go & Versioning, Part 1) and research!rsc: Minimal Version Selection (Go & Versioning, Part 4)
In my opinion, Nix is a very neat idea with a messy implementation and a community which is difficult to stomach from a business stability perspective. As a result, Iâd rather keep Nix as something a little more peripheral and instead make use of Bazel or another option which integrates well with Nix but otherwise doesnât require Nix to continue existing to work.
I think that depends on how you do it. Being able to have, say, the main JSON parsing library and the main time handling library optionally depend on each other for integrations is quite useful, and the inability to do that has been a source of pain in the Rust community.
This has security implications, since many package formats have no way to make an update as âsecurity critical, do not use versions before thisâ.
+1, LTS releases need to be supported.