The Nixpkgs Architecture Team wants to convene a working group for coming up with a CLI tool for Nixpkgs.
This tool would have a similar relationship to Nixpkgs as
nixos-option does to NixOS.
nixos-option it should live in Nixpkgs so it can be kept in strict sync.
We’ll be organizing this working group with regular hacking sessions, so if you’re interested in joining - let us know! Our first task will be creating a tool to efficiently scrape package metadata from
nixpkgs ( more info below ).
We’re looking for a shepherd for this project and additional contributors to get the ball rolling.
Nixpkgs has tons of domain-specific concepts that are not appropriate to include in Nix proper.
Currently, we have an awkward compromise where commands like
nix develop, and
nix shell assume and “ad hoc, informally-specified” subset of these concepts, but this is the worst of both worlds:
- Nixpkgs cannot evolve freely, because it can’t break Nix’s assumptions.Examples:
stdenv-setup and misc pkgs: Revert to space-deliminated propagated-* … · NixOS/nixpkgs@f6f40e3 · GitHub could not switch away from space-separation for
- check-meta: use system tuple in platforms · NixOS/nixpkgs@a52e317 · GitHub / meta.platforms is broken · Issue #60345 · NixOS/nixpkgs · GitHub could not switch from list of support platform to more abstract “open world” descriptions
- stdenv-setup and misc pkgs: Revert to space-deliminated propagated-* … · NixOS/nixpkgs@f6f40e3 · GitHub could not switch away from space-separation for
- Nix never does everything people want with these commands.Endless issues are opened about them.Examples:
nix shell: set MANPATH for installables that have a man dir by sternenseemann · Pull Request #4702 · NixOS/nix · GitHub
MANPATHnot being set caues problems. Offloading responsibility to Nixpkgs (as discussed here!) was proposed.
nix-env: Use pname and version attrs in -q by jtojnar · Pull Request #4463 · NixOS/nix · GitHub
nix-env --query --metahas broken hack for of
- nix shell: set MANPATH for installables that have a man dir by sternenseemann · Pull Request #4702 · NixOS/nix · GitHub
The benefit aren’t just defensive — avoiding the use of Nix commands which constrain Nixpkgs.
Having separate commands also opens the door to making tons of domain-specific functionality more accessible!
- Far richer meta fields, e.g. with language-specific ecosystem extensions are possible. Can present this information to users much better.
- Contributer tools, like that for https://github.com/NixOS/rfcs/pull/140, can take advantage of how the code is structured.
- Smart shells that now how to combine packages (for working on multiple things at once) and other tricks are possible.
The “possibility” part is the most fun an exciting.
But it is also open-ended, and that is dangerous for a new working group.
A precise narrow goal can keep things on track, and then momentum can be built for later.
nix-env --query --available --meta invocation in
pkgs/top-level/make-tarball.nix with invocation of a new CLI command.
nix-env: Use pname and version attrs in -q by jtojnar · Pull Request #4463 · NixOS/nix · GitHub is no longer needed because the new command handles
version correctly without needing Nix to understand them.
Make new CLI residing in Nixpkgs like
Invoke it instead.
At first, this is just an internal tool for
It can be as unstable as we like, since it and its invocation live in the same repo (Nixpkgs).
Tools for humans can come later, and only then do we need to start thinking about stability.
It doesn’t need to use Nix lib as a library, but doing so is explicitly allowed.
There is work to make a new, more stable C interface for Nix to allow using languages other than C++, but we should not wait for it to be ready.
Rather, our new CLI and
nixos-option can both serve as additional motivation for it to be finished.