Nixpkgs Architecture Team Creation

Development Nixpkgs
#1

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 :slight_smile:

15 Likes
Tweag + Nix dev update #34
Tweag + Nix dev update #33
#2

@admins Can you create a Discourse topic for Governance > Nixpkgs Architecture Team?

#3

@infinisil in Category Reorganization 2022 I’m working on reorganizing categories right now. How about a Development>Nixpkgs category instead?

#4

Sounds good! (extra words for min post length)

#5

Here is the Development>Nixpkgs category

1 Like
#6

The name made me first think of supporting more obscure architectures (RISC-V, POWER9, etc.). Not sure how much can be done about that, though.

1 Like
#7

Love this.

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.

4 Likes
#8

Wow just read the team page – ambitious.

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.

Thank you!

1 Like
#9

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.

11 Likes
#10

It being a monorepo is a superpower. I interpret this as an umbrella topic for stuff like the implementation of RFC 92 or improving the PR queue.

Two sides of the same coin perhaps. I’m in favor of moving it into nixpkgs.

4 Likes
#11

noo, please don’t! no superpowers, just normal…

#12

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

#13

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.

Hosted by Flying Circus.