4 ms·
There's been some discussion around this, where tools like Nix and Bazel do a bunch of work figuring out how to get various packages working in their ecosystem,
by rtpg 3y ago
There's been some discussion around this, where tools like Nix and Bazel do a bunch of work figuring out how to get various packages working in their ecosystem, but often fail to actually get that work upstreamed in a reasonable way.
For example, if you have a JS project with a package.json, Nix offers node2nix as a way to transform that package.json into Nix-like expressions. But in an alternate universe npm and lockfiles would "work" well enough to where we wouldn't need to rely on nix for package pinning.
There's all this work put into reproducibility that thinks that the answers are around adding wrappers around the existing tooling. It's good as a last resort, but if those efforts were going more into each language's ecosystem may we would end up in a scenario where each packaging tool didn't have to come up with its own magic way of doing things.
Nix and Bazel are complex because they try to hard to work well despite the tooling, rather than getting tooling to a place where all these layers of hacks were not an issue. And so downstream of that, "simple" tools become too complex from all the incidental complexity introduced by this way of doing things.
- eptcyka 3y agoInstead 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 agoMost 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!