3 ms·

Instead of relying on npm and maven and other language specific tooling, maybe we could rely on Nix to do the package management instead? NPM, Cargo, maven, wha

Instead of relying on npm and maven and other language specific tooling, maybe we could rely on Nix to do the package management instead? NPM, Cargo, maven, whatever Python people think is good this Thursday, Go's reluctant dependency manager are all solving the same problems. And every single one of them could do a better job.

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 ago
  Yet 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 ago
    The 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!

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 ago
Yet 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 ago
  The 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!