I’m currently working to found the Nixpkgs Architecture Team, with the goal of solving bigger architectural issues in nixpkgs, such as:
The inconsistency and variety of override mechanisms
The file structure of /pkgs and how they relate to all-packages.nix
The problem of nixpkgs becoming too big for a single repository
And many more
You can read more about the motivation and goals on the team page, I really think this is what nixpkgs needs right now!
The team will hold public discussions, mainly on #nixpkgs-architecture:nixos.org and the weekly meetings. Feel free to join if you’re interested in listening in or bringing your opinion/experience!
While anybody can join the discussion, being a team member means that you’ll have to reach consensus on issues with other team members to make final decisions. If you’re interested in joining the team, please take a look at the team section.
Note that this team is still being formed. The first meeting will be held next week, but the workings of the team and its organization is still to be fully figured out. While I wrote the initial draft, I’d love to get feedback here or in #nixpkgs-architecture:nixos.org. Also feel free to give ideas as to what the team should work on
I’ve been thinking about this – although nixpkg is a “source of truth” at a given moment; having a higher bar that all package derivations should be easily overridable to alternate sources and versions is key.
I see too many packages though that have variables in a let clause that make it such that overriding the derivation isn’t straightforward.
I would be interested in seeing a new repo just to demonstrate some new core concepts or proof-of work of how things can look which ideally tackle some of the issues raised.
Before the “splitting everything into flakes” idea gets up again. That is not a solution for the problem and just increases maintainer overhead. Especially for the nixos directory which often gets updated or created together with a package.
A good example of a split out repository is nixos-hardware (which should get more love) because it is slowly changing and often can be used with multiple nixos versions.
There are also multiple program developed inside of nixpkgs which should get their own repositories like mkYarnPackage or nixos-option and I am sure we will find some more.
I can’t say that I am neither in favor nor against splitting nixpkgs up.
If we actually wish to play around with this idea we could start with separating lib/mkderivation/bootstrap and other builders, which should result in a base flake that rarely gets updated with ~1000 derivations
There are some projects, like Nix itself, for example, that define a “flake.nix” right in their own source tree. Even if we keep the mono-repo, I think it would be useful to have a mechanism for re-exporting these packages through nixpkgs. I don’t think we should discourage project maintainers from keeping a flake.nix in their source tree by suggesting they have to duplicate their package in nixpkgs as well.
@ryantm Could you give me permission to change the topic of posts? The topic is sometimes used for posts not relevant to the nixpkgs architecture, like this, this or this. I could fix these cases manually myself if I get permission for that. Or maybe the topic needs to be renamed (I’d propose Development/Nixpkgs Architecture), which hopefully makes it better for the future
