From 48015469cc2c71bb08cea1b48b74dec4df6d7d0e Mon Sep 17 00:00:00 2001 From: quantenzitrone Date: Sat, 24 Jan 2026 21:23:27 +0100 Subject: [PATCH 01/23] RFC 197: package set definitons initial commit --- rfcs/0197-package-set-definitions.md | 149 +++++++++++++++++++++++++++ 1 file changed, 149 insertions(+) create mode 100644 rfcs/0197-package-set-definitions.md diff --git a/rfcs/0197-package-set-definitions.md b/rfcs/0197-package-set-definitions.md new file mode 100644 index 000000000..7f63346b2 --- /dev/null +++ b/rfcs/0197-package-set-definitions.md @@ -0,0 +1,149 @@ +--- +feature: nixpkgs package set location +start-date: 2026-01-24 +author: quantenzitrone +co-authors: (find a buddy later to help out with the RFC) +shepherd-team: (names, to be nominated and accepted by RFC steering committee) +shepherd-leader: (name to be appointed by RFC steering committee) +related-issues: (will contain links to implementation PRs) +--- + +# Summary +[summary]: #summary + +Different ideas on how to handle package sets in nixpkgs. + +# Motivation +[motivation]: #motivation + +- 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 +- *your goal here* + +# Idea 1: new directory for package sets + +Proof-Of-Concept implementation in https://github.com/NixOS/nixpkgs/pull/482538 and https://github.com/NixOS/nixpkgs/pull/482543 + +## Detailed design + +- Create a new directory under `pkgs/`, e.g. `pkgs/sets` that contains package sets. + - For example `pkgs/sets/fishPlugins` `pkgs/sets/python3Packages`. +- Each packageset has a `packageset.nix`, that functions as an entrypoint to the package set. +- 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 + `packageset.nix` again with different arguments. + +## Advantages + +- flexibility + +## Drawbacks + +- all packagesets have to handle their shit themselves, so no maintainer merging, by-name + autocalling and stuff without the additional work +- *your drawback here* + +## Unresolved Questions + +- *your question here* + +# Idea 2: nested by-name structure + +Proof-Of-Concept implementation in https://github.com/NixOS/nixpkgs/pull/483432 + +## Detailed design + +- Package sets are done in a nested `by-name` structure under `pkgs/by-name`, e.g. + `fishPlugins.puffer` would be in `by-name/fi/fishPlugins/pu/puffer`. +- To distinguish packages from packagesets we have to mark packagesets somehow, for example with a + file `by-name/fi/fishPlugins/.packageset`, if that file exists, it's called as a packageset, + if not the `package.nix` must exist and is called as a package. + +## Advantages + +- clear package separation +- reuse of RFC 140 concepts +- making maintainer merging work for this is probably relatively simple + +## Drawbacks + +- unresolved questions +- *your drawback here* + +## Unresolved Questions + +- 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? + +# Idea 3: package sets in `pkgs/by-name` (probably worse than Idea 2 in every way) + +Proof-Of-Concept implementation in https://github.com/NixOS/nixpkgs/pull/483128 + +## Detailed design + +- Instead of `by-name//` we have `by-name//`, so e.g. + `fishPlugins.puffer` would go in `by-name/fi/fishPlugins.puffer`. +- The `top-level/by-name-overlay.nix` will call all folders in a `` that contain a dot as a + package set. + +## Advantages + +- clear package separation +- reuse of RFC 140 concepts +- making maintainer merging work for this is probably easy + +## Drawbacks + +- huge shards due to package sets + - currently only few shards like `li` are too large for GitHubs UI, but with this idea a lot of + shards like `py` (`python3Packages`), `ha` (`haskellPackages`) or `vi` (`vimPlugins`) will be + huge as well. +- unresolved questions + +## Unresolved Questions + +- 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? + +# Detailed design +[design]: #detailed-design + +TODO: decide for one of the above ideas + +# Examples and Interactions +[examples-and-interactions]: #examples-and-interactions + +TODO + +# Drawbacks +[drawbacks]: #drawbacks + +TODO + +# Alternatives +[alternatives]: #alternatives + +TODO: move other designs here once decided + +# Prior art +[prior-art]: #prior-art + +- https://github.com/NixOS/nixpkgs/issues/482537 +- https://github.com/NixOS/nixpkgs/issues/432625 +- `tclPackages` has their own `by-name` structure https://github.com/NixOS/nixpkgs/pull/344716 +- attempt to move `nushellPlugins` to `by-name` https://github.com/NixOS/nixpkgs/pull/482961 + +# Unresolved questions +[unresolved]: #unresolved-questions + +What parts of the design are still TBD or unknowns? + +# Future work +[future]: #future-work + +What future work, if any, would be implied or impacted by this feature without being directly part of the work? From 9573e0f68b14944e2b1f7a1a787de48bb2dfdc89 Mon Sep 17 00:00:00 2001 From: quantenzitrone Date: Sat, 24 Jan 2026 21:43:43 +0100 Subject: [PATCH 02/23] Idea 1: easy transition advantage --- rfcs/0197-package-set-definitions.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/rfcs/0197-package-set-definitions.md b/rfcs/0197-package-set-definitions.md index 7f63346b2..a263ffac8 100644 --- a/rfcs/0197-package-set-definitions.md +++ b/rfcs/0197-package-set-definitions.md @@ -37,6 +37,8 @@ Proof-Of-Concept implementation in https://github.com/NixOS/nixpkgs/pull/482538 ## Advantages - flexibility +- easy transition + - for a lot of package sets just move the folder and rename the `default.nix` to `packageset.nix` ## Drawbacks From bb11e6adc702fbeb6cca1eac93714c059d0e4a50 Mon Sep 17 00:00:00 2001 From: quantenzitrone Date: Sun, 25 Jan 2026 01:48:46 +0100 Subject: [PATCH 03/23] collapsible idea sections test --- rfcs/0197-package-set-definitions.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/rfcs/0197-package-set-definitions.md b/rfcs/0197-package-set-definitions.md index a263ffac8..46f1c0870 100644 --- a/rfcs/0197-package-set-definitions.md +++ b/rfcs/0197-package-set-definitions.md @@ -21,8 +21,13 @@ Different ideas on how to handle package sets in nixpkgs. - auto updates with r-ryantm + merge bot maintainer merging - *your goal here* +
+ + # Idea 1: new directory for package sets + + Proof-Of-Concept implementation in https://github.com/NixOS/nixpkgs/pull/482538 and https://github.com/NixOS/nixpkgs/pull/482543 ## Detailed design @@ -50,6 +55,8 @@ Proof-Of-Concept implementation in https://github.com/NixOS/nixpkgs/pull/482538 - *your question here* +
+ # Idea 2: nested by-name structure Proof-Of-Concept implementation in https://github.com/NixOS/nixpkgs/pull/483432 From 625449cc5a39be4116dc407bbb340cdb8e3bf61d Mon Sep 17 00:00:00 2001 From: quantenzitrone Date: Sun, 25 Jan 2026 01:50:58 +0100 Subject: [PATCH 04/23] collapsible sections worked, so all of them now --- rfcs/0197-package-set-definitions.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/rfcs/0197-package-set-definitions.md b/rfcs/0197-package-set-definitions.md index 46f1c0870..342b2af37 100644 --- a/rfcs/0197-package-set-definitions.md +++ b/rfcs/0197-package-set-definitions.md @@ -57,8 +57,13 @@ Proof-Of-Concept implementation in https://github.com/NixOS/nixpkgs/pull/482538 +
+ + # Idea 2: nested by-name structure + + Proof-Of-Concept implementation in https://github.com/NixOS/nixpkgs/pull/483432 ## Detailed design @@ -87,8 +92,15 @@ Proof-Of-Concept implementation in https://github.com/NixOS/nixpkgs/pull/483432 - How do we handle versioned package sets? - How do we move large package sets? +
+ +
+ + # Idea 3: package sets in `pkgs/by-name` (probably worse than Idea 2 in every way) + + Proof-Of-Concept implementation in https://github.com/NixOS/nixpkgs/pull/483128 ## Detailed design @@ -119,6 +131,8 @@ Proof-Of-Concept implementation in https://github.com/NixOS/nixpkgs/pull/483128 - How do we handle versioned package sets? - How do we move large package sets? +
+ # Detailed design [design]: #detailed-design From 1d7fb7fcedb9c468b6ec509f70684984a18b518e Mon Sep 17 00:00:00 2001 From: quantenzitrone Date: Sun, 25 Jan 2026 01:57:55 +0100 Subject: [PATCH 05/23] `tree` like output for visualization --- rfcs/0197-package-set-definitions.md | 56 ++++++++++++++++++++++++++++ 1 file changed, 56 insertions(+) diff --git a/rfcs/0197-package-set-definitions.md b/rfcs/0197-package-set-definitions.md index 342b2af37..32f8c635e 100644 --- a/rfcs/0197-package-set-definitions.md +++ b/rfcs/0197-package-set-definitions.md @@ -39,6 +39,22 @@ Proof-Of-Concept implementation in https://github.com/NixOS/nixpkgs/pull/482538 - Versioned package sets like `python316Packages` are done in `all-packages.nix` by calling the `packageset.nix` again with different arguments. +``` +pkgs +├── by-name +│ └── ... +└── sets + ├── fishPlugins + │ ├── + │ ... + │ └── packageset.nix <- entrypoint to package set + └── python3Packages + │ ├── + │ ... + │ └── packageset.nix <- entrypoint to package set + ... +``` + ## Advantages - flexibility @@ -74,6 +90,28 @@ Proof-Of-Concept implementation in https://github.com/NixOS/nixpkgs/pull/483432 file `by-name/fi/fishPlugins/.packageset`, if that file exists, it's called as a packageset, if not the `package.nix` must exist and is called as a package. +``` +pkgs +└── by-name + ├── 0_ + ... + ├── fi + │ ├── fiano + │ ├── fiche + │ ├── ... + │ ├── fishnet + │ ├── fishPlugins + │ │ ├── as + │ │ │ └── async-prompt + │ │ ├── au + │ │ ... + │ │ └── z_ + │ │ └── z + │ ├── fishy + │ ... + ... +``` + ## Advantages - clear package separation @@ -110,6 +148,24 @@ Proof-Of-Concept implementation in https://github.com/NixOS/nixpkgs/pull/483128 - The `top-level/by-name-overlay.nix` will call all folders in a `` that contain a dot as a package set. +``` +pkgs +└── by-name + ├── 0_ + ... + ├── fi + │ ├── fiano + │ ├── fiche + │ ├── ... + │ ├── fishnet + │ ├── fishPlugins.async-prompt + │ ├── fishPlugins.autopair + │ ├── fishPlugins.z + │ ├── fishy + │ ... + ... +``` + ## Advantages - clear package separation From 2c7fc9f6d724ade76f1608ecb5d4dee8c95723e9 Mon Sep 17 00:00:00 2001 From: Zitrone <74491719+quantenzitrone@users.noreply.github.com> Date: Sun, 25 Jan 2026 01:20:25 +0000 Subject: [PATCH 06/23] Update rfcs/0197-package-set-definitions.md Co-authored-by: Yohann Boniface --- rfcs/0197-package-set-definitions.md | 1 + 1 file changed, 1 insertion(+) diff --git a/rfcs/0197-package-set-definitions.md b/rfcs/0197-package-set-definitions.md index 32f8c635e..026ad9986 100644 --- a/rfcs/0197-package-set-definitions.md +++ b/rfcs/0197-package-set-definitions.md @@ -101,6 +101,7 @@ pkgs │ ├── ... │ ├── fishnet │ ├── fishPlugins + │ │ ├── .packageset │ │ ├── as │ │ │ └── async-prompt │ │ ├── au From b0c8c39d873beff22016ef17abd12342778e84fb Mon Sep 17 00:00:00 2001 From: quantenzitrone Date: Sun, 25 Jan 2026 02:43:13 +0100 Subject: [PATCH 07/23] transform idea 1 to be more strict about the directory structure --- rfcs/0197-package-set-definitions.md | 53 +++++++++++++++++++++------- 1 file changed, 40 insertions(+), 13 deletions(-) diff --git a/rfcs/0197-package-set-definitions.md b/rfcs/0197-package-set-definitions.md index 026ad9986..3714815c7 100644 --- a/rfcs/0197-package-set-definitions.md +++ b/rfcs/0197-package-set-definitions.md @@ -24,7 +24,7 @@ Different ideas on how to handle package sets in nixpkgs.
-# Idea 1: new directory for package sets +# Idea 1: new directory for package sets with by-name structure @@ -32,9 +32,18 @@ Proof-Of-Concept implementation in https://github.com/NixOS/nixpkgs/pull/482538 ## Detailed design -- Create a new directory under `pkgs/`, e.g. `pkgs/sets` that contains package sets. - - For example `pkgs/sets/fishPlugins` `pkgs/sets/python3Packages`. +- Create a new directory under `pkgs/`, e.g. `pkgs/sets-by-name` that contains package sets. + - For example `pkgs/sets-by-name/fishPlugins`, `pkgs/sets-by-name/python3Packages`. - Each packageset has a `packageset.nix`, that functions as an entrypoint to the package set. + - The `packageset.nix` has some code like `top-level/by-name-overlay.nix` that autocalls packages + in the folder. + - with sharding for large package sets like `python3Packages` + - without sharding for small package sets like `fishPlugins` + - threshold for sharding is to be discussed + - 1000 (including extra files like `README.md` and `packageset.nix`) should the the absolute + maximum because of GitHubs UI + - 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 `packageset.nix` again with different arguments. @@ -43,28 +52,46 @@ Proof-Of-Concept implementation in https://github.com/NixOS/nixpkgs/pull/482538 pkgs ├── by-name │ └── ... -└── sets - ├── fishPlugins - │ ├── +└── sets-by-name + ├── fishPlugins <- small package set so no sharding + │ ├── async-prompt + │ │ └── package.nix + │ ├── autopair + │ │ └── package.nix │ ... + │ ├── z + │ │ └── package.nix │ └── packageset.nix <- entrypoint to package set - └── python3Packages - │ ├── + │ + ├── python3Packages <- large package set with sharding + │ ├── a2 + │ │ └── a2wsgi + │ │ └── package.nix + │ ├── aa │ ... + │ ├── zx + │ │ ├── zxcvbn + │ │ │ └── package.nix + │ │ ├── zxcvbn-rs-py + │ │ │ └── package.nix + │ │ └── zxing-cpp + │ │ └── package.nix │ └── packageset.nix <- entrypoint to package set ... ``` ## Advantages -- flexibility -- easy transition - - for a lot of package sets just move the folder and rename the `default.nix` to `packageset.nix` +- accessibility through github ui navigation (better than idea 2 and 3) +- clear package separation +- reuse of RFC 140 concepts +- making maintainer merging work for this is probably relatively simple + - implement tooling to work for a non-sharded by-name structure + - enable tooling on all subdirectories of `pkgs/sets-by-name` ## Drawbacks -- all packagesets have to handle their shit themselves, so no maintainer merging, by-name - autocalling and stuff without the additional work +- autocalling logic has to be duplicated for each package set - *your drawback here* ## Unresolved Questions From a2853b8c97dca355aaf42e9313e2959e31bf7eeb Mon Sep 17 00:00:00 2001 From: quantenzitrone Date: Sun, 25 Jan 2026 02:46:27 +0100 Subject: [PATCH 08/23] add python3Packages by-name to prior art --- rfcs/0197-package-set-definitions.md | 1 + 1 file changed, 1 insertion(+) diff --git a/rfcs/0197-package-set-definitions.md b/rfcs/0197-package-set-definitions.md index 3714815c7..61fb87248 100644 --- a/rfcs/0197-package-set-definitions.md +++ b/rfcs/0197-package-set-definitions.md @@ -240,6 +240,7 @@ TODO: move other designs here once decided # Prior art [prior-art]: #prior-art +- `by-name` stucture for `python3Packages` https://github.com/NixOS/nixpkgs/pull/449896 https://github.com/NixOS/nixpkgs-vet/pull/180 - https://github.com/NixOS/nixpkgs/issues/482537 - https://github.com/NixOS/nixpkgs/issues/432625 - `tclPackages` has their own `by-name` structure https://github.com/NixOS/nixpkgs/pull/344716 From 84b56869c35d72c71cd92977b555076cbaa8eb93 Mon Sep 17 00:00:00 2001 From: quantenzitrone Date: Sun, 25 Jan 2026 02:47:56 +0100 Subject: [PATCH 09/23] Idea3: attrpath in directory names drawback --- rfcs/0197-package-set-definitions.md | 1 + 1 file changed, 1 insertion(+) diff --git a/rfcs/0197-package-set-definitions.md b/rfcs/0197-package-set-definitions.md index 61fb87248..6fe2dee82 100644 --- a/rfcs/0197-package-set-definitions.md +++ b/rfcs/0197-package-set-definitions.md @@ -206,6 +206,7 @@ pkgs - currently only few shards like `li` are too large for GitHubs UI, but with this idea a lot of shards like `py` (`python3Packages`), `ha` (`haskellPackages`) or `vi` (`vimPlugins`) will be huge as well. +- directory names as attrpaths is sketchy - unresolved questions ## Unresolved Questions From c592d416b3721efa4e65bbd3a587f998fe443348 Mon Sep 17 00:00:00 2001 From: quantenzitrone Date: Sun, 25 Jan 2026 02:50:53 +0100 Subject: [PATCH 10/23] Idea {2,3}: inaccessibility of sets like lixPackages --- rfcs/0197-package-set-definitions.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/rfcs/0197-package-set-definitions.md b/rfcs/0197-package-set-definitions.md index 6fe2dee82..ef0721720 100644 --- a/rfcs/0197-package-set-definitions.md +++ b/rfcs/0197-package-set-definitions.md @@ -149,6 +149,8 @@ pkgs ## Drawbacks - unresolved questions +- some package sets like `lixPackages` (behind all `lib*` packages) will not be accessible through + GitHub UI - *your drawback here* ## Unresolved Questions @@ -206,6 +208,8 @@ pkgs - currently only few shards like `li` are too large for GitHubs UI, but with this idea a lot of shards like `py` (`python3Packages`), `ha` (`haskellPackages`) or `vi` (`vimPlugins`) will be huge as well. +- some package sets like `lixPackages` (behind all `lib*` packages) will not be accessible through + GitHub UI - directory names as attrpaths is sketchy - unresolved questions From ee5f96df2abbc6d60de0a68d909efb4c16df4825 Mon Sep 17 00:00:00 2001 From: quantenzitrone Date: Sun, 25 Jan 2026 02:53:52 +0100 Subject: [PATCH 11/23] Idea {2,3}: package sets in pkgs/by-name is sketchy --- rfcs/0197-package-set-definitions.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/rfcs/0197-package-set-definitions.md b/rfcs/0197-package-set-definitions.md index ef0721720..bcd75fd49 100644 --- a/rfcs/0197-package-set-definitions.md +++ b/rfcs/0197-package-set-definitions.md @@ -151,6 +151,7 @@ pkgs - unresolved questions - some package sets like `lixPackages` (behind all `lib*` packages) will not be accessible through GitHub UI +- having package sets in `pkgs/by-name` may not fit the spirit of rfc 140 - *your drawback here* ## Unresolved Questions @@ -210,6 +211,7 @@ pkgs huge as well. - some package sets like `lixPackages` (behind all `lib*` packages) will not be accessible through GitHub UI +- having package sets in `pkgs/by-name` may not fit the spirit of rfc 140 - directory names as attrpaths is sketchy - unresolved questions From d47b2ad1172c2c1698301d580fdee049e6789c1c Mon Sep 17 00:00:00 2001 From: quantenzitrone Date: Sun, 25 Jan 2026 03:27:16 +0100 Subject: [PATCH 12/23] more concrete numbers --- rfcs/0197-package-set-definitions.md | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/rfcs/0197-package-set-definitions.md b/rfcs/0197-package-set-definitions.md index bcd75fd49..02303aec8 100644 --- a/rfcs/0197-package-set-definitions.md +++ b/rfcs/0197-package-set-definitions.md @@ -149,8 +149,7 @@ pkgs ## Drawbacks - unresolved questions -- some package sets like `lixPackages` (behind all `lib*` packages) will not be accessible through - GitHub UI +- `lixPackages` (behind all `lib*` packages) will not be accessible through GitHubs UI - having package sets in `pkgs/by-name` may not fit the spirit of rfc 140 - *your drawback here* @@ -206,9 +205,13 @@ pkgs ## Drawbacks - huge shards due to package sets - - currently only few shards like `li` are too large for GitHubs UI, but with this idea a lot of - shards like `py` (`python3Packages`), `ha` (`haskellPackages`) or `vi` (`vimPlugins`) will be - huge as well. + - currently only few shards like `li` are too large for GitHubs UI, but with this idea more shards + will be huge as well + - specifically 12 more shards `em`, `gn`, `ha`, `ho`, `oc`, `pe`, `py`, `rp`, `sb`, + `te`, `ty`, `vi` and `vi` (for `emacsPackages`, `gnomeExtensions`, `haskellPackages`, + `home-assistant-component-tests`, `ocamlPackages`, `pearlPackages`, `python3Packages`, + `rPackages`, `sbclPackages`, `texlivePackages`, `typstPackages` and `vimPlugins`) will be + inaccessible. - some package sets like `lixPackages` (behind all `lib*` packages) will not be accessible through GitHub UI - having package sets in `pkgs/by-name` may not fit the spirit of rfc 140 From 882c21af49438e81b404888504f0e312445326d1 Mon Sep 17 00:00:00 2001 From: quantenzitrone Date: Sun, 25 Jan 2026 16:54:51 +0100 Subject: [PATCH 13/23] Idea 1 only allows top-level package sets --- rfcs/0197-package-set-definitions.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/rfcs/0197-package-set-definitions.md b/rfcs/0197-package-set-definitions.md index 02303aec8..b2994f295 100644 --- a/rfcs/0197-package-set-definitions.md +++ b/rfcs/0197-package-set-definitions.md @@ -28,7 +28,7 @@ Different ideas on how to handle package sets in nixpkgs. -Proof-Of-Concept implementation in https://github.com/NixOS/nixpkgs/pull/482538 and https://github.com/NixOS/nixpkgs/pull/482543 +Proof-Of-Concept implementation in https://github.com/NixOS/nixpkgs/pull/482538 ## Detailed design @@ -92,6 +92,7 @@ pkgs ## Drawbacks - autocalling logic has to be duplicated for each package set +- only allows top level package sets - *your drawback here* ## Unresolved Questions @@ -145,6 +146,7 @@ pkgs - clear package separation - reuse of RFC 140 concepts - making maintainer merging work for this is probably relatively simple +- allows nested package sets ## Drawbacks @@ -201,6 +203,7 @@ pkgs - clear package separation - reuse of RFC 140 concepts - making maintainer merging work for this is probably easy +- allows nested package sets ## Drawbacks From 8f16dc095e974d1f5e68fbfdfd61f15f2e792613 Mon Sep 17 00:00:00 2001 From: quantenzitrone Date: Sun, 25 Jan 2026 17:11:03 +0100 Subject: [PATCH 14/23] another idea 3 drawback --- rfcs/0197-package-set-definitions.md | 1 + 1 file changed, 1 insertion(+) diff --git a/rfcs/0197-package-set-definitions.md b/rfcs/0197-package-set-definitions.md index b2994f295..cffcde939 100644 --- a/rfcs/0197-package-set-definitions.md +++ b/rfcs/0197-package-set-definitions.md @@ -218,6 +218,7 @@ pkgs - some package sets like `lixPackages` (behind all `lib*` packages) will not be accessible through GitHub UI - having package sets in `pkgs/by-name` may not fit the spirit of rfc 140 +- it's called pkgs/by-**name** and not pkgs/by-**attrpath** - directory names as attrpaths is sketchy - unresolved questions From b26025e9edc184fa8778b64d70974f9e93bb8a98 Mon Sep 17 00:00:00 2001 From: quantenzitrone Date: Sun, 25 Jan 2026 17:28:52 +0100 Subject: [PATCH 15/23] scrap idea 3 --- rfcs/0197-package-set-definitions.md | 44 ++++++++++++++-------------- 1 file changed, 22 insertions(+), 22 deletions(-) diff --git a/rfcs/0197-package-set-definitions.md b/rfcs/0197-package-set-definitions.md index cffcde939..420c8c232 100644 --- a/rfcs/0197-package-set-definitions.md +++ b/rfcs/0197-package-set-definitions.md @@ -164,10 +164,30 @@ pkgs
+# Detailed design +[design]: #detailed-design + +TODO: decide for one of the above ideas + +# Examples and Interactions +[examples-and-interactions]: #examples-and-interactions + +TODO + +# Drawbacks +[drawbacks]: #drawbacks + +TODO + +# Alternatives +[alternatives]: #alternatives + +TODO: move other designs here once decided +
-# Idea 3: package sets in `pkgs/by-name` (probably worse than Idea 2 in every way) +# Idea 3: package sets in `pkgs/by-name` (scrapped) @@ -213,7 +233,7 @@ pkgs - specifically 12 more shards `em`, `gn`, `ha`, `ho`, `oc`, `pe`, `py`, `rp`, `sb`, `te`, `ty`, `vi` and `vi` (for `emacsPackages`, `gnomeExtensions`, `haskellPackages`, `home-assistant-component-tests`, `ocamlPackages`, `pearlPackages`, `python3Packages`, - `rPackages`, `sbclPackages`, `texlivePackages`, `typstPackages` and `vimPlugins`) will be + `rPackages`, `sbclPackages`, `texlivePackages`, `typstPackages` and `vimPlugins`) could become inaccessible. - some package sets like `lixPackages` (behind all `lib*` packages) will not be accessible through GitHub UI @@ -231,26 +251,6 @@ pkgs
-# Detailed design -[design]: #detailed-design - -TODO: decide for one of the above ideas - -# Examples and Interactions -[examples-and-interactions]: #examples-and-interactions - -TODO - -# Drawbacks -[drawbacks]: #drawbacks - -TODO - -# Alternatives -[alternatives]: #alternatives - -TODO: move other designs here once decided - # Prior art [prior-art]: #prior-art From 5c955067c96d4604a52210e6345aae2717270230 Mon Sep 17 00:00:00 2001 From: quantenzitrone Date: Sun, 25 Jan 2026 17:50:10 +0100 Subject: [PATCH 16/23] improve goals --- rfcs/0197-package-set-definitions.md | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/rfcs/0197-package-set-definitions.md b/rfcs/0197-package-set-definitions.md index 420c8c232..7ff9ad550 100644 --- a/rfcs/0197-package-set-definitions.md +++ b/rfcs/0197-package-set-definitions.md @@ -16,9 +16,12 @@ Different ideas on how to handle package sets in nixpkgs. # Motivation [motivation]: #motivation -- 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 +- get rid of the package categories as directories (decided in RFC 140 and 146) +- bring the benefits of by-name to package sets + - merge bot maintainer merging + - scaleability + - isolation + - vetting - *your goal here*
From 2775b53946be97e009a2a8ce87c304074eb0892f Mon Sep 17 00:00:00 2001 From: quantenzitrone Date: Sun, 25 Jan 2026 18:33:13 +0100 Subject: [PATCH 17/23] tooling has to be made to work for multiple directories --- rfcs/0197-package-set-definitions.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/rfcs/0197-package-set-definitions.md b/rfcs/0197-package-set-definitions.md index 7ff9ad550..b37246eec 100644 --- a/rfcs/0197-package-set-definitions.md +++ b/rfcs/0197-package-set-definitions.md @@ -90,6 +90,7 @@ pkgs - reuse of RFC 140 concepts - making maintainer merging work for this is probably relatively simple - implement tooling to work for a non-sharded by-name structure + - implement tooling to work for multiple directories https://github.com/NixOS/nixpkgs-vet/pull/180 - enable tooling on all subdirectories of `pkgs/sets-by-name` ## Drawbacks @@ -117,8 +118,8 @@ Proof-Of-Concept implementation in https://github.com/NixOS/nixpkgs/pull/483432 - Package sets are done in a nested `by-name` structure under `pkgs/by-name`, e.g. `fishPlugins.puffer` would be in `by-name/fi/fishPlugins/pu/puffer`. -- To distinguish packages from packagesets we have to mark packagesets somehow, for example with a - file `by-name/fi/fishPlugins/.packageset`, if that file exists, it's called as a packageset, +- To distinguish packages from package sets we have to mark package sets somehow, for example with a + file `by-name/fi/fishPlugins/.packageset`, if that file exists, it's called as a package set, if not the `package.nix` must exist and is called as a package. ``` From 53f107c67d8f05873a9607b77e097afd3661faf1 Mon Sep 17 00:00:00 2001 From: Zitrone <74491719+quantenzitrone@users.noreply.github.com> Date: Sun, 25 Jan 2026 18:50:38 +0000 Subject: [PATCH 18/23] Update rfcs/0197-package-set-definitions.md Co-authored-by: Yohann Boniface --- rfcs/0197-package-set-definitions.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/rfcs/0197-package-set-definitions.md b/rfcs/0197-package-set-definitions.md index b37246eec..b28e914f3 100644 --- a/rfcs/0197-package-set-definitions.md +++ b/rfcs/0197-package-set-definitions.md @@ -118,8 +118,7 @@ Proof-Of-Concept implementation in https://github.com/NixOS/nixpkgs/pull/483432 - Package sets are done in a nested `by-name` structure under `pkgs/by-name`, e.g. `fishPlugins.puffer` would be in `by-name/fi/fishPlugins/pu/puffer`. -- To distinguish packages from package sets we have to mark package sets somehow, for example with a - file `by-name/fi/fishPlugins/.packageset`, if that file exists, it's called as a package set, +- A marker is required in order to distinguish package sets from simple packages, such as using a `.packageset` file (example: `by-name/fi/fishPlugins/.packageset`) if not the `package.nix` must exist and is called as a package. ``` From 3c4cbdddfba91ade089692619e277922e4daf7f6 Mon Sep 17 00:00:00 2001 From: quantenzitrone Date: Sun, 25 Jan 2026 21:21:13 +0100 Subject: [PATCH 19/23] Idea 1: redesign with auto called by-structure and without unsharded sets --- rfcs/0197-package-set-definitions.md | 102 ++++++++++++++++----------- 1 file changed, 60 insertions(+), 42 deletions(-) diff --git a/rfcs/0197-package-set-definitions.md b/rfcs/0197-package-set-definitions.md index b28e914f3..4fa947a83 100644 --- a/rfcs/0197-package-set-definitions.md +++ b/rfcs/0197-package-set-definitions.md @@ -27,7 +27,7 @@ Different ideas on how to handle package sets in nixpkgs.
-# Idea 1: new directory for package sets with by-name structure +# Idea 1: `pkgs/sets-by-name` @@ -37,50 +37,70 @@ Proof-Of-Concept implementation in https://github.com/NixOS/nixpkgs/pull/482538 - Create a new directory under `pkgs/`, e.g. `pkgs/sets-by-name` that contains package sets. - For example `pkgs/sets-by-name/fishPlugins`, `pkgs/sets-by-name/python3Packages`. -- Each packageset has a `packageset.nix`, that functions as an entrypoint to the package set. - - The `packageset.nix` has some code like `top-level/by-name-overlay.nix` that autocalls packages - in the folder. - - with sharding for large package sets like `python3Packages` - - without sharding for small package sets like `fishPlugins` - - threshold for sharding is to be discussed - - 1000 (including extra files like `README.md` and `packageset.nix`) should the the absolute - maximum because of GitHubs UI - - 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 - `packageset.nix` again with different arguments. +- Each package set is sharded like `pkgs/by-name`. +- The following additional have to exist for each package set. + - `functions.nix`: definitons of functions, like `buildFishPlugin`, `buildPythonPackage`. + - `overrides.nix`: overrides of packages, like `top-level/all-packages.nix` currently functions as + an overlay for `by-name` packages. + - This is something we try to keep empty. Most, maybe all, overrides can be inlined in the + package. + - `aliases.nix`: aliases for aliases in package sets behind `optionalAttrs config.allowAliases` + (like `top-level/aliases.nix`). +- All package sets with their sharded packages, overlayed with their functions, overrides and + aliases are automatically called by `top-level/package-sets-by-name.nix`. +- Versioned package sets like `python316Packages` are done in `all-packages.nix` by overriding the + default version package set. +- Versioned package sets without a default version will have to override the default version with + an error. + - e.g. `nextcloud*Packages` are in `sets-by-name/nextcloundPackages` and thus autocalled by + `top-level/package-sets-by-name.nix`, however we will have an alias in `top-level/aliases.nix` + that says + ```nix + { + nextcloudPackages = throw "Please use nextcloudPackages for a specific nextcloud ersion e.g. nextcloud32Packages."; + } + ``` ``` pkgs ├── by-name │ └── ... -└── sets-by-name - ├── fishPlugins <- small package set so no sharding - │ ├── async-prompt - │ │ └── package.nix - │ ├── autopair - │ │ └── package.nix - │ ... - │ ├── z - │ │ └── package.nix - │ └── packageset.nix <- entrypoint to package set - │ - ├── python3Packages <- large package set with sharding - │ ├── a2 - │ │ └── a2wsgi - │ │ └── package.nix - │ ├── aa - │ ... - │ ├── zx - │ │ ├── zxcvbn - │ │ │ └── package.nix - │ │ ├── zxcvbn-rs-py - │ │ │ └── package.nix - │ │ └── zxing-cpp - │ │ └── package.nix - │ └── packageset.nix <- entrypoint to package set +├── sets-by-name +│ ├── fishPlugins +│ │ ├── as +│ │ │ ├── async-prompt +│ │ │ ... └── package.nix +│ │ ├── au +│ │ ... +│ │ ├── z_ +│ │ │ └── z +│ │ │ └── package.nix +│ │ ├── aliases.nix +│ │ ├── functions.nix +│ │ └── overrides.nix +│ │ +│ ├── python3Packages +│ │ ├── a2 +│ │ │ └── a2wsgi +│ │ │ └── package.nix +│ │ ├── aa +│ │ ... +│ │ ├── zx +│ │ │ ├── zxcvbn +│ │ │ │ └── package.nix +│ │ │ ├── zxcvbn-rs-py +│ │ │ │ └── package.nix +│ │ │ └── zxing-cpp +│ │ │ └── package.nix +│ │ ├── aliases.nix +│ │ ├── functions.nix +│ │ └── overrides.nix +│ ... +└── top-level + ├── all-packages.nix <- calls all versioned package sets + ├── by-name-overlay.nix <- used to autocall sharded packages (no change required) ... + └── package-sets-by-name.nix <- autocalls all sets by name ``` ## Advantages @@ -88,14 +108,12 @@ pkgs - accessibility through github ui navigation (better than idea 2 and 3) - clear package separation - reuse of RFC 140 concepts -- making maintainer merging work for this is probably relatively simple - - implement tooling to work for a non-sharded by-name structure +- making maintainer merging and nixpkgs-vet work for this is probably relatively simple - implement tooling to work for multiple directories https://github.com/NixOS/nixpkgs-vet/pull/180 - enable tooling on all subdirectories of `pkgs/sets-by-name` ## Drawbacks -- autocalling logic has to be duplicated for each package set - only allows top level package sets - *your drawback here* From 2cf527e4bf43f2f0bbca0e41445ebd23203088a1 Mon Sep 17 00:00:00 2001 From: quantenzitrone Date: Sun, 25 Jan 2026 23:52:58 +0100 Subject: [PATCH 20/23] Idea 2: drop, make idea 1 the default --- rfcs/0197-package-set-definitions.md | 105 ++++++++++----------------- 1 file changed, 37 insertions(+), 68 deletions(-) diff --git a/rfcs/0197-package-set-definitions.md b/rfcs/0197-package-set-definitions.md index 4fa947a83..c2d195e41 100644 --- a/rfcs/0197-package-set-definitions.md +++ b/rfcs/0197-package-set-definitions.md @@ -1,17 +1,20 @@ --- -feature: nixpkgs package set location +feature: nixpkgs package sets by-name start-date: 2026-01-24 author: quantenzitrone co-authors: (find a buddy later to help out with the RFC) shepherd-team: (names, to be nominated and accepted by RFC steering committee) shepherd-leader: (name to be appointed by RFC steering committee) -related-issues: (will contain links to implementation PRs) +related-issues: https://github.com/NixOS/nixpkgs/pull/482538 --- # Summary [summary]: #summary -Different ideas on how to handle package sets in nixpkgs. +Package sets like `fishPlugins` or `python3Packages` move to a `pkgs/by-name` like structure in +`pkgs/sets-by-name/`. + +This doesn't apply to package sets that are auto-generated like `haskellPackages`. # Motivation [motivation]: #motivation @@ -27,13 +30,8 @@ Different ideas on how to handle package sets in nixpkgs.
-# Idea 1: `pkgs/sets-by-name` - - - -Proof-Of-Concept implementation in https://github.com/NixOS/nixpkgs/pull/482538 - -## Detailed design +# Detailed design +[design]: #detailed-design - Create a new directory under `pkgs/`, e.g. `pkgs/sets-by-name` that contains package sets. - For example `pkgs/sets-by-name/fishPlugins`, `pkgs/sets-by-name/python3Packages`. @@ -103,41 +101,44 @@ pkgs └── package-sets-by-name.nix <- autocalls all sets by name ``` -## Advantages +Proof-Of-Concept implementation in https://github.com/NixOS/nixpkgs/pull/482538 -- accessibility through github ui navigation (better than idea 2 and 3) -- clear package separation -- reuse of RFC 140 concepts -- making maintainer merging and nixpkgs-vet work for this is probably relatively simple - - implement tooling to work for multiple directories https://github.com/NixOS/nixpkgs-vet/pull/180 - - enable tooling on all subdirectories of `pkgs/sets-by-name` +# Examples and Interactions +[examples-and-interactions]: #examples-and-interactions -## Drawbacks +TODO + +# Drawbacks +[drawbacks]: #drawbacks - only allows top level package sets - *your drawback here* ## Unresolved Questions +- Does the handling of versioned package sets work like this? +- How do we move large package sets? - *your question here* -
+# Alternatives +[alternatives]: #alternatives
-# Idea 2: nested by-name structure +## Idea 2: nested by-name structure -Proof-Of-Concept implementation in https://github.com/NixOS/nixpkgs/pull/483432 +outdated Proof-Of-Concept implementation in https://github.com/NixOS/nixpkgs/pull/483432 -## Detailed design +### Detailed design -- Package sets are done in a nested `by-name` structure under `pkgs/by-name`, e.g. +- Idea 1, but sets are in the existing `pkgs/by-name` structure instead of `pkgs/sets-by-name`, e.g. `fishPlugins.puffer` would be in `by-name/fi/fishPlugins/pu/puffer`. -- A marker is required in order to distinguish package sets from simple packages, such as using a `.packageset` file (example: `by-name/fi/fishPlugins/.packageset`) - if not the `package.nix` must exist and is called as a package. +- Additionally a marker is required in order to distinguish package sets from simple packages, + such as using a `.packageset` file (example: `by-name/fi/fishPlugins/.packageset`). + If not the `package.nix` must exist and is called as a package. ``` pkgs @@ -162,59 +163,29 @@ pkgs ... ``` -## Advantages +### Advantages -- clear package separation -- reuse of RFC 140 concepts -- making maintainer merging work for this is probably relatively simple +- no new directory, just extend `pkgs/by-name` - allows nested package sets -## Drawbacks +### Drawbacks -- unresolved questions - `lixPackages` (behind all `lib*` packages) will not be accessible through GitHubs UI -- having package sets in `pkgs/by-name` may not fit the spirit of rfc 140 +- having package sets in `pkgs/by-name` may not fit the spirit of RFC 140 - *your drawback here* -## Unresolved Questions - -- 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? -
-# Detailed design -[design]: #detailed-design - -TODO: decide for one of the above ideas - -# Examples and Interactions -[examples-and-interactions]: #examples-and-interactions - -TODO - -# Drawbacks -[drawbacks]: #drawbacks - -TODO - -# Alternatives -[alternatives]: #alternatives - -TODO: move other designs here once decided -
-# Idea 3: package sets in `pkgs/by-name` (scrapped) +## Idea 3: package sets in `pkgs/by-name` (scrapped) Proof-Of-Concept implementation in https://github.com/NixOS/nixpkgs/pull/483128 -## Detailed design +### Detailed design - Instead of `by-name//` we have `by-name//`, so e.g. `fishPlugins.puffer` would go in `by-name/fi/fishPlugins.puffer`. @@ -239,14 +210,12 @@ pkgs ... ``` -## Advantages +### Advantages -- clear package separation -- reuse of RFC 140 concepts -- making maintainer merging work for this is probably easy +- no new directory, just extend `pkgs/by-name` - allows nested package sets -## Drawbacks +### Drawbacks - huge shards due to package sets - currently only few shards like `li` are too large for GitHubs UI, but with this idea more shards @@ -258,12 +227,12 @@ pkgs inaccessible. - some package sets like `lixPackages` (behind all `lib*` packages) will not be accessible through GitHub UI -- having package sets in `pkgs/by-name` may not fit the spirit of rfc 140 +- having package sets in `pkgs/by-name` may not fit the spirit of RFC 140 - it's called pkgs/by-**name** and not pkgs/by-**attrpath** - directory names as attrpaths is sketchy - unresolved questions -## Unresolved Questions +### Unresolved Questions - How do we handle functions like `fishPlugins.buildFishPlugin`? - How do we handle aliases? From fa81fb3bec329a00b3c7fa2afa364fccd68eac46 Mon Sep 17 00:00:00 2001 From: quantenzitrone Date: Sun, 25 Jan 2026 23:55:35 +0100 Subject: [PATCH 21/23] minor fixes --- rfcs/0197-package-set-definitions.md | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/rfcs/0197-package-set-definitions.md b/rfcs/0197-package-set-definitions.md index c2d195e41..1bc8292eb 100644 --- a/rfcs/0197-package-set-definitions.md +++ b/rfcs/0197-package-set-definitions.md @@ -27,9 +27,6 @@ This doesn't apply to package sets that are auto-generated like `haskellPackages - vetting - *your goal here* -
- - # Detailed design [design]: #detailed-design @@ -179,7 +176,7 @@ pkgs
-## Idea 3: package sets in `pkgs/by-name` (scrapped) +## Idea 3: package sets in `pkgs/by-name` From d0bb18b31675ecf2313a1c71e7760be3261eae74 Mon Sep 17 00:00:00 2001 From: quantenzitrone Date: Sun, 25 Jan 2026 23:59:29 +0100 Subject: [PATCH 22/23] move unresolved questions to proper location --- rfcs/0197-package-set-definitions.md | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/rfcs/0197-package-set-definitions.md b/rfcs/0197-package-set-definitions.md index 1bc8292eb..460b051a3 100644 --- a/rfcs/0197-package-set-definitions.md +++ b/rfcs/0197-package-set-definitions.md @@ -111,12 +111,6 @@ TODO - only allows top level package sets - *your drawback here* -## Unresolved Questions - -- Does the handling of versioned package sets work like this? -- How do we move large package sets? -- *your question here* - # Alternatives [alternatives]: #alternatives @@ -250,7 +244,9 @@ pkgs # Unresolved questions [unresolved]: #unresolved-questions -What parts of the design are still TBD or unknowns? +- Does the handling of versioned package sets work like this? +- How do we move large package sets? +- *your question here* # Future work [future]: #future-work From 329891e1df35c4a7d87cb40a7f7a1bf6b0a2c33f Mon Sep 17 00:00:00 2001 From: quantenzitrone Date: Mon, 26 Jan 2026 00:25:10 +0100 Subject: [PATCH 23/23] fix type --- rfcs/0197-package-set-definitions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/0197-package-set-definitions.md b/rfcs/0197-package-set-definitions.md index 460b051a3..004d19670 100644 --- a/rfcs/0197-package-set-definitions.md +++ b/rfcs/0197-package-set-definitions.md @@ -47,7 +47,7 @@ This doesn't apply to package sets that are auto-generated like `haskellPackages default version package set. - Versioned package sets without a default version will have to override the default version with an error. - - e.g. `nextcloud*Packages` are in `sets-by-name/nextcloundPackages` and thus autocalled by + - e.g. `nextcloud*Packages` are in `sets-by-name/nextcloudPackages` and thus autocalled by `top-level/package-sets-by-name.nix`, however we will have an alias in `top-level/aliases.nix` that says ```nix