3 ms·
Most language package managers have some notion of dependency resolution, since various deps declare bounds for their dependencies instead of pinned versions (s
by rtpg 3y ago
Most language package managers have some notion of dependency resolution, since various deps declare bounds for their dependencies instead of pinned versions (since otherwise frameworks would be impossible to upgrade).
Nix the language doesn't have such a thing (would be a bit of a category error), and nixpkgs the ecosystem is so far away from that kind of thing...
Language ecosystems around sharing source code cannot exist as they do today if every dependency pinned its dependencies to specific versions. Source distribution like that has different requirements than binaries.
- eptcyka 3y agoYet we still have lock files. The version constraints can just be another piece of metadata that a given derivation carries with itself. You have to distinguish between declaring a dependency and using one in the compilation of a thing.
- rtpg 3y agoThe point is that from a UX perspective, people want to be able to specify loose dependencies, and then for a constraint solver to then provide an overall set of dependencies where all of these holds. You're saying "just use nix". Nix does not provide this. This is a fundamental feature of programming language package managers. I would love for Nix to have an interesting answer to this problem, but I think that if nixpkgs continues to exist in its current form (following more of an apt model), it will be hard for the Nix community to come up with an answer that fits well. Nixpkgs is mostly about distributing compiled assets, while programming language package managers are mostly about distributing source code. The important parts are different!