4 ms·

Nix has a namespace problem. Most package managers exist independently from the packages they manage. Nix integrates them directly into its monolithic source t

Nix has a namespace problem. Most package managers exist independently from the packages they manage. Nix integrates them directly into its monolithic source tree. So when you ask nix to install a package, what version does it give you? The original method is channels: each channel follows a branch of the NixOS/nixpkgs GitHub repo. Every package is given a global name in nixpkgs/pkgs/top-level/all-packages.nix This is...a mess. Versions? They go in the name sometimes, like python2. Names aren't consistent everywhere, either. The name of a package in all-packages.nix might need to be different from the name in its own derivation source. Good luck finding it. Not every package gets a global name, either. Some are moved into separate attributes sets. Some get both. Figuring out what magic words need to go into your configuration.nix (or at the end of a command) is a lot more difficult than it should be. Even more difficult is figuring out what needs to go in a new package. Flakes try to dodge this mess by moving it out of the global namespace, out of the nixpkgs source tree, and into the source of the thing you want packaged. I'm not a huge fan.

pxc 3y ago
> Most package managers exist independently from the packages they manage. Nix integrates them directly into its monolithic source tree. A couple of minor points: the Nix package collection lives in the Nixpkgs repo. The package manager's source has its own repo. > So when you ask nix to install a package, what version does it give you? > The original method is channels: each channel follows a branch of the NixOS/nixpkgs GitHub repo. Every package is given a global name in nixpkgs/pkgs/top-level/all-packages.nix > This is...a mess. Versions? The monorepo of package declarations (build recipes) is traditional for source-based package managers like Nix. Anyway, it doesn't preclude versioning in a more traditional way. Gentoo's Portage, for instance, has a tree of build recipes but also supports multiple versions, in-tree, in a first-class way. Maybe Nixpkgs or a similar package set could have something like that some day. Overall, I agree that the namespacing in Nixpkgs is messy and also that replacing Nixpkgs with assorted flakes that refer to one another as inputs doesn't seem great.
- thomastjeffery 3y ago
  Thanks for the clarification. It's also worth mentioning that NixOS itself is in the nixpkgs repo. That sorta makes sense. Sorta. There are two reasons I'm really frustrated with the namespace problem: 1. Discoverability I have spent a very significant amount of time just trying to answer the simple question, "what is the package named?" The worst part is when the package does have an obvious top-level/all-packages.nix name, but that isn't the one you are supposed to use! Sometimes, a package will need to change more of your environment than PATH, like udev rules or systemd units. In that case, it will have a totally different attribute like services.openssh.enable; but there is no clear way to learn this is the case, or what the attribute is! I still don't have a good sense of how nixpkgs is organized, and I've been using NixOS as a daily driver for 5 years. 2. Flexibility Writing a new derivation (package) is way too difficult. Documentation is improving, but it's still not nearly good enough. There are just too many layers, and too much magic. God forbid you need a different version of a library. Of course, that's the problem that flakes solve, but it's still hard to find what you need, even when it's there.

pxc 3y ago

> Most package managers exist independently from the packages they manage. Nix integrates them directly into its monolithic source tree. A couple of minor points: the Nix package collection lives in the Nixpkgs repo. The package manager's source has its own repo. > So when you ask nix to install a package, what version does it give you? > The original method is channels: each channel follows a branch of the NixOS/nixpkgs GitHub repo. Every package is given a global name in nixpkgs/pkgs/top-level/all-packages.nix > This is...a mess. Versions? The monorepo of package declarations (build recipes) is traditional for source-based package managers like Nix. Anyway, it doesn't preclude versioning in a more traditional way. Gentoo's Portage, for instance, has a tree of build recipes but also supports multiple versions, in-tree, in a first-class way. Maybe Nixpkgs or a similar package set could have something like that some day. Overall, I agree that the namespacing in Nixpkgs is messy and also that replacing Nixpkgs with assorted flakes that refer to one another as inputs doesn't seem great.

thomastjeffery 3y ago
Thanks for the clarification. It's also worth mentioning that NixOS itself is in the nixpkgs repo. That sorta makes sense. Sorta. There are two reasons I'm really frustrated with the namespace problem: 1. Discoverability I have spent a very significant amount of time just trying to answer the simple question, "what is the package named?" The worst part is when the package does have an obvious top-level/all-packages.nix name, but that isn't the one you are supposed to use! Sometimes, a package will need to change more of your environment than PATH, like udev rules or systemd units. In that case, it will have a totally different attribute like services.openssh.enable; but there is no clear way to learn this is the case, or what the attribute is! I still don't have a good sense of how nixpkgs is organized, and I've been using NixOS as a daily driver for 5 years. 2. Flexibility Writing a new derivation (package) is way too difficult. Documentation is improving, but it's still not nearly good enough. There are just too many layers, and too much magic. God forbid you need a different version of a library. Of course, that's the problem that flakes solve, but it's still hard to find what you need, even when it's there.