[RFC 0197] package sets by-name #197

quantenzitrone · 2026-01-24T20:37:17Z

This is currently a collection of ideas on how to handle package sets in the future.
Looking for feedback and ideas.

rendered

rfcs/0197-package-set-definitions.md

Sigmanificient

First time interacting with an RFC, i hope i am not making comment that are too dumb 😅

rfcs/0197-package-set-definitions.md

Sigmanificient · 2026-01-25T00:58:40Z

thanks for adding trees ❤️

Sigmanificient · 2026-01-25T01:00:36Z

i think a drawback from idea 3 is that we end up with attrpath in directory names

rfcs/0197-package-set-definitions.md

Co-authored-by: Yohann Boniface <edhyjox@gmail.com>

rfcs/0197-package-set-definitions.md

SigmaSquadron

I was discussing this privately with @Sigmanificient earlier today, and he helped me organise my thoughts on this.

rfcs/0197-package-set-definitions.md

SigmaSquadron · 2026-01-25T05:33:35Z

rfcs/0197-package-set-definitions.md

+
+- get rid of the package categories as directories.
+- make packages in package sets take advantage of the by-name greatness
+  - auto updates with r-ryantm + merge bot maintainer merging


I think our implementation plan should be separated into four stages:

Create interfaces for package sets that uses the same functions as by-name to callPackage packages from sharded directories, with additional extensions for package set versioning.

Update nixpkgs-vet to expand the existing linting checks to the new package sets.

Migrate all package sets into the new interface when it makes sense to do so, or move the children of smaller sets into by-name as top-level packages.

Add new rules to nixpkgs-merge-bot to allow unprivileged merging to package sets.

We can't move into the next stage before the previous one is complete, so let's not think about the later stages just now.

rfcs/0197-package-set-definitions.md

SigmaSquadron · 2026-01-25T05:36:45Z

rfcs/0197-package-set-definitions.md

+
+## Unresolved Questions
+
+- How do we handle functions like `fishPlugins.buildFishPlugin`?


(Answering because this applies to idea 1)

I never thought it made sense for functions and derivation builders to be inside package sets. I think our Go infrastructure has the right idea: move them to the top-level, and version them in the attribute name. fishPlugins.buildFishPlugin can just be moved to the top-level, while python313Packages.buildPythonApplication becomes buildPython313Application on the top-level. We can deal with this at stage 3, where we migrate everything over.

This proposal is awkward with Python where you have CPython and PyPy and then language version-dialects within them, and even worse for Common Lisp where you have same base language but multiple compatible implementations with their completely own versioning.

i also think keeping functions in package sets is fine

SigmaSquadron · 2026-01-25T05:42:56Z

rfcs/0197-package-set-definitions.md

+
+- How do we handle functions like `fishPlugins.buildFishPlugin`?
+- How do we handle aliases?
+- How do we handle versioned package sets?


(Answering because this applies to idea 1)

I generally think it's a good idea to think of Nixpkgs as having three types of package infrastructure systems:

Top-level packages, which nowadays go to by-name;

Simple package sets, like fishPlugins, which are easier to implement in this new interface as we can simply call them as we do by-name packages and shove the resulting set into fishPlugins from the top-level.

Versioned package sets, like python3Packages, which are by far the most complex. I think we should absolutely get the input of the primary maintainers of these sets here before we move forward. There are many concerns regarding updating versioned sets, and default aliases, as well as edge cases like python3.pkgs and python3Packages. In the end, having something that is no worse to maintain as it was before would be ideal.

Auto generated package sets like haskellPackages.

i want handle both 2 and 3 with this RFC

SigmaSquadron · 2026-01-25T05:48:28Z

rfcs/0197-package-set-definitions.md

+- How do we handle functions like `fishPlugins.buildFishPlugin`?
+- How do we handle aliases?
+- How do we handle versioned package sets?
+- How do we move large package sets?


(Answering because this applies to idea 1)

Some of them are easy enough. If we resolve the aforementioned issues with the python edge cases, it should be a simple matter of moving and renaming files. OCaml should also be pretty simple.

The generated sets, like Haskell, Node, Lisp and R, will be impossible, though. Those packages don't actually exist as separate files in Nixpkgs, and are instead imported from some other upstream.

This is something that again, we'll have to get the input of package set maintainers on. Moving everything over will end up being a case-by-case basis.

rfcs/0197-package-set-definitions.md

SigmaSquadron · 2026-01-25T05:54:58Z

rfcs/0197-package-set-definitions.md

+  - the `packageset.nix` can include aliases, functions like `fishPlugins.buildFishPlugin` and
+    overrides.
+- The `packageset.nix` files are autocalled by some `pkgs/top-level/by-name-overlay.nix` like file.
+- Versioned package sets like `python316Packages` are done in `all-packages.nix` by calling the


That seems good to me. As mentioned in #197 (comment), this is conditional on the approval of the current versioned package set maintainers.

rfcs/0197-package-set-definitions.md

infinisil

In addition to the comments, also a meta-comment: While it's really great to create RFC documents like these, we don't need the lengthy RFC process anymore to get them approved, because if Nixpkgs committers can't agree on it, we can escalate to the SC-appointed Nixpkgs core team, which has the authority to make a call.

Probably still beneficial for Nixpkgs to keep discussions for such changes outside the Nixpkgs repo itself due to the noise there, but otherwise I'd suggest to PR this to an adr/¹ directory in Nixpkgs.

From https://adr.github.io/, which is very similar ↩

rfcs/0197-package-set-definitions.md

Co-authored-by: Yohann Boniface <edhyjox@gmail.com>

7c6f434c · 2026-01-25T19:45:15Z

rfcs/0197-package-set-definitions.md

+# Summary
+[summary]: #summary
+
+Different ideas on how to handle package sets in nixpkgs.


What is a package set? There are some that do not have a direct top-level name. I think in general some places of the text is written for a package set that comes with its set of expressions, while there are cases where meaningfully sets share a large fraction of the expressions.

…sets

rfcs/0197-package-set-definitions.md

SigmaSquadron · 2026-01-27T06:51:45Z

rfcs/0197-package-set-definitions.md

+  - scaleability
+  - isolation
+  - vetting
+- *your goal here*


Updates across package sets are very different. I don't think this should be a goal of this RFC, but instead something that can be developed separately as an updateScript that nixpkgs-update can pick up.

7c6f434c · 2026-01-27T11:50:35Z

rfcs/0197-package-set-definitions.md

+│   │   ├── zx
+│   │   │   ├── zxcvbn
+│   │   │   │   └── package.nix
+│   │   │   ├── zxcvbn-rs-py
+│   │   │   │   └── package.nix
+│   │   │   └── zxing-cpp
+│   │   │       └── package.nix
+│   │   ├── aliases.nix


So, a few files mixed within the shard list?

The alternative would be putting them in pkgs/top-level. It seems more sensible to have them at the root of the package set instead.

Another alternative is to have one more level inside the package set before the shards (by-name subdirectory, I guess).

Which would also make more manageable packagesets that benefit from having a few more support files inside the package set but not as a packageset package.

That might require us to filter out that directory from the autocaller function, but it's a good idea as well.

i think they meant

pkgs/sets ├── fishPlugins │ ├── by-name │ │ ├── as │ │ │ ├── async-prompt │ │ │ ... └── package.nix │ │ ├── au │ │ ... │ │ └── z_ │ │ └── z │ │ └── package.nix │ └── top-level │ ├── aliases.nix │ ├── functions.nix │ └── overrides.nix

Well, it is a matter of taste if top-level is needed or the files would go into the root of the package set.

Well, it is a matter of taste if top-level is needed or the files would go into the root of the package set.
Exactly.

So I was thinking like this could happen:

pkgs/ ├── fi/fishPlugins │ ├── by-name │ │ ├── as │ │ │ ├── async-prompt │ │ │ ... └── package.nix │ │ ├── au │ │ ... │ │ └── z_ │ │ └── z │ │ └── package.nix └── aliases.nix └── functions.nix └── overrides.nix

By name is used in the case so that way you don't get confused easily with two by-names.
Another idea to improve this, is making the by-name in package sets to something like packages could work? So like:

pkgs/ ├── fi/fishPlugins │ ├── packages │ │ ├── as │ │ │ ├── async-prompt │ │ │ ... └── package.nix │ │ ├── au │ │ ... │ │ └── z_ │ │ └── z │ │ └── package.nix └── aliases.nix └── functions.nix └── overrides.nix

If you look at the POC implementation, you can also see that buildFishPlugin is in sets-by-name/fishPlugins/buildFishPlugin.nix.
For some package sets there might be larger amounts of functions so the package set folder could become crowded.
We could also just inline functions into functions.nix and require that no additional files are in the package set tree root.

I don't understand that. This mixes shards and non-shards under pkgs itself? And puts the package sets as normal packages? I am probably misreading the diagram.

I don't understand that. This mixes shards and non-shards under pkgs itself? And puts the package sets as normal packages? I am probably misreading the diagram.

Well the ideally in the packages it's another set then there would be default.nix which would hook it up.

I am probably misreading the diagram.

Probably 👀

7c6f434c · 2026-01-27T14:59:08Z

By the way, lispPackages treated as sbclPackages but also needed for ccl.pkgs and ecl.pkgs seems even worse semantically than override luajit = lua5_3 or the other way round that current attempts to minimise all-packages.nix at any cost promote. So this should include pins from the beginning.

quantenzitrone · 2026-01-27T22:08:01Z

Guys I think we need to decide on and merge #83 first.
Especially the foo.pkgs vs fooPackages part.
I've always thought of package sets as top level attributes like fooPackages, because that is what is exposed on https://search.nixos.org, but it seems that is not always the case.

SigmaSquadron · 2026-01-27T22:14:24Z

#83 is unfortunately abandoned. I don't think we should depend on it, but rather replace it.

RFC 197: package set definitons initial commit

4801546

quantenzitrone changed the title ~~RFC 197: package set definitons initial commit~~ [RFC 0197] package set definitons initial commit Jan 24, 2026

quantenzitrone changed the title ~~[RFC 0197] package set definitons initial commit~~ [RFC 0197] package set definitons Jan 24, 2026

quantenzitrone mentioned this pull request Jan 24, 2026

directory structure for package sets NixOS/nixpkgs#482537

Open

Idea 1: easy transition advantage

9573e0f

quantenzitrone commented Jan 24, 2026

View reviewed changes

rfcs/0197-package-set-definitions.md Outdated Show resolved Hide resolved

Sigmanificient reviewed Jan 24, 2026

View reviewed changes

quantenzitrone added 3 commits January 25, 2026 01:48

collapsible idea sections test

bb11e6a

collapsible sections worked, so all of them now

625449c

tree like output for visualization

1d7fb7f

Sigmanificient reviewed Jan 25, 2026

View reviewed changes

rfcs/0197-package-set-definitions.md Show resolved Hide resolved

quantenzitrone and others added 5 commits January 25, 2026 01:20

Update rfcs/0197-package-set-definitions.md

2c7fc9f

Co-authored-by: Yohann Boniface <edhyjox@gmail.com>

transform idea 1 to be more strict about the directory structure

b0c8c39

add python3Packages by-name to prior art

a2853b8

Idea3: attrpath in directory names drawback

84b5686

Idea {2,3}: inaccessibility of sets like lixPackages

c592d41

Sigmanificient reviewed Jan 25, 2026

View reviewed changes

rfcs/0197-package-set-definitions.md Outdated Show resolved Hide resolved

quantenzitrone added 2 commits January 25, 2026 02:53

Idea {2,3}: package sets in pkgs/by-name is sketchy

ee5f96d

more concrete numbers

d47b2ad

quantenzitrone commented Jan 25, 2026

View reviewed changes

rfcs/0197-package-set-definitions.md Outdated Show resolved Hide resolved

quantenzitrone commented Jan 25, 2026

View reviewed changes

rfcs/0197-package-set-definitions.md Outdated Show resolved Hide resolved

SigmaSquadron reviewed Jan 25, 2026

View reviewed changes

infinisil reviewed Jan 25, 2026

View reviewed changes

rfcs/0197-package-set-definitions.md Outdated Show resolved Hide resolved

rfcs/0197-package-set-definitions.md Outdated Show resolved Hide resolved

quantenzitrone added 5 commits January 25, 2026 16:54

Idea 1 only allows top-level package sets

882c21a

another idea 3 drawback

8f16dc0

scrap idea 3

b26025e

improve goals

5c95506

tooling has to be made to work for multiple directories

2775b53

Sigmanificient reviewed Jan 25, 2026

View reviewed changes

rfcs/0197-package-set-definitions.md Outdated Show resolved Hide resolved

Update rfcs/0197-package-set-definitions.md

53f107c

Co-authored-by: Yohann Boniface <edhyjox@gmail.com>

7c6f434c reviewed Jan 25, 2026

View reviewed changes

Idea 1: redesign with auto called by-structure and without unsharded …

3c4cbdd

…sets

qweered reviewed Jan 25, 2026

View reviewed changes

rfcs/0197-package-set-definitions.md Outdated Show resolved Hide resolved

quantenzitrone added 3 commits January 25, 2026 23:52

Idea 2: drop, make idea 1 the default

2cf527e

minor fixes

fa81fb3

move unresolved questions to proper location

d0bb18b

quantenzitrone changed the title ~~[RFC 0197] package set definitons~~ [RFC 0197] package sets by-name Jan 25, 2026

Sigmanificient reviewed Jan 25, 2026

View reviewed changes

rfcs/0197-package-set-definitions.md Outdated Show resolved Hide resolved

fix type

329891e

Eveeifyeve reviewed Jan 27, 2026

View reviewed changes

7c6f434c reviewed Jan 27, 2026

View reviewed changes

quantenzitrone mentioned this pull request Jan 27, 2026

tracking: list of package sets NixOS/nixpkgs#484418

Open


		## Unresolved Questions

		- How do we handle functions like `fishPlugins.buildFishPlugin`?

Uh oh!

[RFC 0197] package sets by-name #197

Are you sure you want to change the base?

[RFC 0197] package sets by-name #197

Conversation

quantenzitrone commented Jan 24, 2026

Uh oh!

Uh oh!

Sigmanificient left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Sigmanificient commented Jan 25, 2026

Uh oh!

Sigmanificient commented Jan 25, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

SigmaSquadron left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

SigmaSquadron Jan 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

SigmaSquadron Jan 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

infinisil left a comment

Choose a reason for hiding this comment

Footnotes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

This comment was marked as off-topic.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

quantenzitrone Jan 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

SigmaSquadron Jan 25, 2026 •

edited

Loading

SigmaSquadron Jan 25, 2026 •

edited

Loading

quantenzitrone Jan 27, 2026 •

edited

Loading

Eveeifyeve Jan 27, 2026 •

edited

Loading

7c6f434c commented Jan 27, 2026 •

edited

Loading