From 48015469cc2c71bb08cea1b48b74dec4df6d7d0e Mon Sep 17 00:00:00 2001 From: quantenzitrone Date: Sat, 24 Jan 2026 21:23:27 +0100 Subject: [PATCH 01/31] 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/31] 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/31] 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/31] 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/31] `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/31] 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/31] 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/31] 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/31] 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/31] 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/31] 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/31] 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/31] 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/31] 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/31] 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/31] 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/31] 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/31] 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/31] 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/31] 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/31] 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/31] 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/31] 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 From 97862ce78a04747e72e9e8c7c29c41d00baf1124 Mon Sep 17 00:00:00 2001 From: quantenzitrone Date: Wed, 4 Mar 2026 11:38:53 +0100 Subject: [PATCH 24/31] rewrite the whole rfc text - decide on fooPackages vs foo.pkgs - incorporate all kinds of package sets - be very detailed, maybe too detailed --- rfcs/0197-package-set-definitions.md | 387 ++++++++++++++++++++++----- 1 file changed, 326 insertions(+), 61 deletions(-) diff --git a/rfcs/0197-package-set-definitions.md b/rfcs/0197-package-set-definitions.md index 004d19670..5e92103e4 100644 --- a/rfcs/0197-package-set-definitions.md +++ b/rfcs/0197-package-set-definitions.md @@ -1,5 +1,5 @@ --- -feature: nixpkgs package sets by-name +feature: nixpkgs package sets start-date: 2026-01-24 author: quantenzitrone co-authors: (find a buddy later to help out with the RFC) @@ -11,10 +11,33 @@ related-issues: https://github.com/NixOS/nixpkgs/pull/482538 # Summary [summary]: #summary -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`. +Package sets (definition see [Detailed Design](#detailed-design) e.g.`fishPlugins`, `python3Packages`) + +- should be top-level attribute sets that contain + - packages + - functions helping these packages + - variables like `version`, `withFoo`, ... + - TBD: other package sets? +- should move to `pkgs/sets/` where + - they must have a directory `pkgs/sets//by-name` + with a sharded `by-name` like structure + that is checked in the CI with `nixpkgs-vet` + - packages in this structure will get all the benefits of `pkgs/by-name` + - they must have files `overrides.nix`, `aliases.nix`, `functions.nix` and `manual-packages.nix` + containing aliases, overrides, functions and packages outside of the `by-name` structure + - are optionally are autocalled + - this would be the case for manually defined package sets + and auto generated package sets + - if there exists a file `pkgs/sets//packageset.nix`, + they have to be manually called + - this would be the case for versioned package sets +- can be versioned for which they: + - are are called multiple times through `packageset.nix` + with the different interpreter/compiler/... versions + - may have a top-level function `For` that allows convenient creation + of new versions + - may be in `passthru` of the package that they depend on + - this can be archived by using the `For` function # Motivation [motivation]: #motivation @@ -25,90 +48,334 @@ This doesn't apply to package sets that are auto-generated like `haskellPackages - scaleability - isolation - vetting +- unify the interface for package sets - *your goal here* # 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`. -- 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/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 - { - nextcloudPackages = throw "Please use nextcloudPackages for a specific nextcloud ersion e.g. nextcloud32Packages."; - } - ``` +## What are package sets? + +Basically attribute sets of packages, functions and other package sets. + +Package sets are often largely auto generated: +- `emacsPackages` from ELPA, MELPA, NONGNU, ... +- `haskellPackages` from hackage +- `rPackages` from CRAN (Comprehensive R Archive Network) +- ... + +Package sets often depend on the version of a base program, such as an interpreter or compiler: +- `{python3*,jupyter,...,mypy*}.pkgs` depends on python interpreter, which can be different versions + and or implementations of python +- `haskell.packages.ghc*` depends on the version of the haskell compiler +- `emacs*.pkgs` depends on the emacs version +- `{sbcl*,clisp,ccl,...}.pkgs` depends on the version/implementation of common lisp +- `ocaml-ng.ocamlPackages*` depends on the version of the ocaml compiler +- ... + +Package sets are sometimes nested: +- `emacsPackages.{melpa,elpa,nongnu}{,Devel}Packages` +- `ocamlPackages.janeStreet` +- `vscode-extensions.*` but thats a whole another mess +- `kdePackages.{gear,frameworks,plasma}` +- ... + +## What should package sets be? + +Package sets should be top-level attribute sets. This means: +- `ocaml-ng.*` will have to move to the top-level +- `vscode-extensions` will be flattened +- TODO: which package sets will have to move? + +Package sets should have an attribute name that is lowerCamelCase. +This intentionally does not comply with the package naming conventions +because package sets are not packages. + +Package sets can contain anything like packages (derivations), functions, booleans, strings +but all non-packages should be related to the package set. + +Package sets will be moved to a new directory `pkgs/sets`. For example: +- `pkgs/sets/fishPlugins` +- `pkgs/sets/haskellPackages` +- `pkgs/sets/python3Packages` +- ... +This means package sets will have a "canonical name", +which will mostly also be the attribute name +with a few exceptions for versioned package sets that don't have a default version. +- e.g. `nextcloud*Packages` will be in `pkgs/sets/nextcloudPackages`, + but there is no `pkgs.nextcloudPackages` + +Package sets in `pkgs/sets` _must_ have a directory `pkgs/sets//by-name` +which is a sharded directory structure for isolated package definitions as defined by RFC 140. +This sharded structure is checked in the CI by `nixpkgs-vet` +and will get the same benefits of `pkgs/by-name` +like merge bot maintainer merging, scaleability, isolation and vetting. +If there are no packages that fit into this structure, it may be empty. + +Package sets in `pkgs/sets` _must_ have a file `pkgs/sets//overrides.nix` +that is an overlay containing overrides for packages in the `by-name` structure +like `top-level/all-packages.nix` currently functions as an overlay for `by-name` packages +This is something we try to keep empty (`final: prev: {}`). +Most, maybe all, overrides can be inlined in the package. +e.g. +```nix +final: prev: { + # inlineability debateable since it complicates overriding + fooFull = final.foo.override { + withMeow = true; + withBeep = true; + }; + + # useless inlineable override + bar = final.callPackage by-name/bar/package.nix { + foo = final.fooFull; + }; +} +``` + +Package sets in `pkgs/sets` _must_ have a file `pkgs/sets//functions.nix` +that is an overlay containing definitons of functions +like `buildFishPlugin`, `buildPythonPackage`. +e.g. +```nix +final: prev: { + buildFooBarPackage = import ./buildFooBarPackage final; +} +``` + +Package sets in `pkgs/sets` _must_ have a file `pkgs/sets//aliases.nix` +that is an overlay containing aliases for packages in package sets behind `optionalAttrs config.allowAliases` +like `top-level/aliases.nix` does for the top-level. +e.g. +```nix +final: prev: +let + inherit (final) lib; +in +{ + # (warnAlias would have to move to lib for this) + fooo = lib.warnAlias "'fooo' has been renamed to 'foo'" final.foo; + awawa_1 = builtins.throw "'awawa_1' has been deprecated, please use a newer version of 'awawa' like 'awawa_2'"; +} +``` + +Package sets in `pkgs/sets` _must_ have a file `pkgs/sets//manual-packages.nix` +that is an overlay containing derivations outside of the `by-name` structure +- **auto generated package sets** don't need to abuse the `overrides.nix` +- the migration of (large) package sets can initially keep the `by-name` structure empty and + only fill it gradually, simplifying the migration of large package sets + +Package sets in `pkgs/sets` _may_ have a file `pkgs/sets//packageset.nix` +which results in them not being called automatically. +The `packageset.nix` _must_ handle the calling of the `by-name` structure +(which should be easy by using `pkgs/top-level/by-name-overlay.nix`) +as well as the files `overrides.nix`, `functions.nix`, `aliases.nix` and `manual-packages.nix`. +Since the `packageset.nix` is not automatically called +there is no need to place any more restrictions on this file, +which allows package sets to be flexible. +Calling these package sets should be done in a file in `pkgs/top-level` e.g. +- `top-level/package-sets.nix` -> have all package sets in one place +- `top-level/all-packages.nix` -> only have autocalled packages in a separate file -> file is small + +If a package set does not have a `packageset.nix`, +it is autocalled by a file in `pkgs/top-level` (e.g. `top-level/package-sets.nix`). + +Versioned package sets +like `python*Packages`, `nextcloud*Packages` +will have to use the manual calling with `packageset.nix` +Example `packageset.nix` (i think this would work but i haven't tested it): +```nix +{ + lib, + newScope, +}: +python: +lib.makeScope newScope ( + self: + lib.fix ( + lib.extend + (x: { + inherit python; + }) + [ + (import ../../top-level/by-name-overlay.nix ./by-name) + (import ./overrides.nix) + (import ./functions.nix) + (import ./aliases.nix) + ] + ) +) +``` + +Versioned package sets may define a top-level function wrapping this e.g. +```nix +{ + pythonPackagesFor = callPackage ../sets/pythonPackages/packageset.nix {}; +} +``` + +Versioned package sets may be in `passthru` of the package that they depend on e.g. +```nix +{ + lib, + stdenv, + # ... + pythonPackgesFor, + # ... +}: +stdenv.mkDerivation (finalAttrs: { + # ... + passthru.pkgs = pythonPackagesFor finalAttrs.finalPackage; + # ... +}) +``` + +## The full directory layout could look like ``` pkgs -├── by-name -│ └── ... -├── sets-by-name +├── sets │ ├── fishPlugins -│ │ ├── as -│ │ │ ├── async-prompt -│ │ │ ... └── package.nix -│ │ ├── au -│ │ ... -│ │ ├── z_ -│ │ │ └── z -│ │ │ └── package.nix +│ │ ├── by-name +│ │ │ ├── as +│ │ │ │ ├── async-prompt +│ │ │ │ ... └── package.nix +│ │ │ ├── au +│ │ │ ... +│ │ │ └── z_ +│ │ │ └── z +│ │ │ └── package.nix │ │ ├── aliases.nix │ │ ├── functions.nix +│ │ ├── mkFishPlugin.nix (could also be inlined in functions.nix) │ │ └── overrides.nix │ │ │ ├── python3Packages -│ │ ├── a2 -│ │ │ └── a2wsgi -│ │ │ └── package.nix -│ │ ├── aa -│ │ ... -│ │ ├── zx -│ │ │ ├── zxcvbn -│ │ │ │ └── package.nix -│ │ │ ├── zxcvbn-rs-py -│ │ │ │ └── package.nix -│ │ │ └── zxing-cpp -│ │ │ └── package.nix +│ │ ├── by-name +│ │ │ ├── a2 +│ │ │ │ └── a2wsgi +│ │ │ │ └── package.nix +│ │ │ ├── aa +│ │ │ ... +│ │ │ └── zx +│ │ │ ├── zxcvbn +│ │ │ │ └── package.nix +│ │ │ ├── zxcvbn-rs-py +│ │ │ │ └── package.nix +│ │ │ └── zxing-cpp +│ │ │ └── package.nix +│ │ ├── functions (could also be inlined in functions.nix) +│ │ │ ├── buildPythonApplication.nix +│ │ │ └── buildPythonPackage.nix │ │ ├── aliases.nix │ │ ├── functions.nix -│ │ └── overrides.nix +│ │ ├── overrides.nix +│ │ └── packageset.nix <- entrypoint for versioned python3Packages │ ... └── top-level - ├── all-packages.nix <- calls all versioned package sets + ├── by-name-overlay.nix <- aliases for deprecated versions of package sets ├── by-name-overlay.nix <- used to autocall sharded packages (no change required) ... - └── package-sets-by-name.nix <- autocalls all sets by name + └── package-sets.nix <- calls all package sets in pkgs/sets +``` + +## `pkgs/top-level/package-sets.nix` could look like + +```nix +self: super: +let + # Because of Nix's import-value cache, importing lib is free + lib = import ../../lib; +in +# autocalled sets +lib.pipe ../sets [ + builtins.readDir + # filter out non directories like README.md + (lib.filterAttrs (_: value: value == "directory")) + # filter out manually called package sets + (lib.filterAttrs (name: _: !(lib.pathExists ../sets/${name}/packageset.nix))) + # autocall + (lib.mapAttrs ( + name: _: + lib.pipe (self: { }) [ + # autocall all sharded by name packages + (lib.extends (import ./by-name-overlay.nix ../sets/${name}/by-name)) + # overlay aliases + (lib.extends ( + self: super: + lib.optionalAttrs self.config.allowAliases (import (../sets/${name}/aliases.nix) self super) + )) + # overlay functions + (lib.extends (import (../sets/${name}/functions.nix))) + # overlay overrides + (lib.extends (import (../sets/${name}/overrides.nix))) + # make a new scope and recurse into it + (lib.makeScope self.newScope) + lib.recurseIntoAttrs + ] + )) +] +# manually called sets +// { + # python + # we only recurse into the newest 2 python versions + python3PackagesFor = self.callPackage ../sets/python3Packages/packageset.nix {}; + python311Packages = self.python3PackagesFor self.python311; + python312Packages = self.python3PackagesFor self.python312; + python313Packages = lib.recurseIntoAttrs (self.python3PackagesFor self.python313); + python314Packages = lib.recurseIntoAttrs (self.python3PackagesFor self.python314); + python3Packages = self.python3PackagesFor self.python314; + pypy311Packages = self.python3PackagesFor self.pypy311; + pypy312Packages = self.python3PackagesFor self.pypy312; + pypy3Packages = pypy312Packages; + + # nextcloud + nextcloudPackagesFor = self.callPackage ../sets/nextcloudPackages/packageset.nix {}; + nextcloud31Packages = self.nextcloudPackagesFor "31"; # idk if it works like this, this is an example + nextcloud32Packages = self.nextcloudPackagesFor "32"; + nextcloud33Packages = self.nextcloudPackagesFor "33"; + + # ... +} ``` -Proof-Of-Concept implementation in https://github.com/NixOS/nixpkgs/pull/482538 +Proof-Of-Concept implementation in https://github.com/NixOS/nixpkgs/pull/482538 (outdated) # Examples and Interactions [examples-and-interactions]: #examples-and-interactions -TODO +## Adding a package to a package set + +1. create `pkgs/sets//by-name///package.nix` +2. write the derivation. +3. check if it works. + +## Deprecating a package in a package set + +1. remove the package + e.g. by removing `pkgs/sets//by-name//` +2. add an alias or throw to `pkgs/sets//aliases.nix` + +## Deprecating an old version of a package set + +1. remove it from `pkgs/top-level/package-sets.nix` +2. add a warning/throw to `pkgs/top-level/aliases.nix` + +## Moving a package set to `pkgs/sets` + +1. move all package definitions to `pkgs/sets/` +2. make sure all required files and folders exist and are in the right format +3. sort aliases, functions and derivations into their respective files +4. if the package is versioned + - make sure the `packageset.nix` exists and includes all the required files + - move the attribute definitons into `pkgs/top-level/package-sets.nix` + - move aliases into `aliases.nix` +6. (optional) move packages to the `by-name` structure where possible # Drawbacks [drawbacks]: #drawbacks -- only allows top level package sets +- only allows top level package sets to benefit from `by-name` benefits - *your drawback here* # Alternatives @@ -244,8 +511,6 @@ pkgs # Unresolved questions [unresolved]: #unresolved-questions -- Does the handling of versioned package sets work like this? -- How do we move large package sets? - *your question here* # Future work From 558d5013ccb6c017b47bc1eb18e8abd95ead345b Mon Sep 17 00:00:00 2001 From: quantenzitrone Date: Wed, 4 Mar 2026 11:53:29 +0100 Subject: [PATCH 25/31] fix typos --- rfcs/0197-package-set-definitions.md | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/rfcs/0197-package-set-definitions.md b/rfcs/0197-package-set-definitions.md index 5e92103e4..78cde2d5e 100644 --- a/rfcs/0197-package-set-definitions.md +++ b/rfcs/0197-package-set-definitions.md @@ -24,7 +24,7 @@ Package sets (definition see [Detailed Design](#detailed-design) e.g.`fishPlugin that is checked in the CI with `nixpkgs-vet` - packages in this structure will get all the benefits of `pkgs/by-name` - they must have files `overrides.nix`, `aliases.nix`, `functions.nix` and `manual-packages.nix` - containing aliases, overrides, functions and packages outside of the `by-name` structure + containing aliases, overrides, functions and packages outside the `by-name` structure - are optionally are autocalled - this would be the case for manually defined package sets and auto generated package sets @@ -32,12 +32,12 @@ Package sets (definition see [Detailed Design](#detailed-design) e.g.`fishPlugin they have to be manually called - this would be the case for versioned package sets - can be versioned for which they: - - are are called multiple times through `packageset.nix` + - are called multiple times through `packageset.nix` with the different interpreter/compiler/... versions - may have a top-level function `For` that allows convenient creation of new versions - may be in `passthru` of the package that they depend on - - this can be archived by using the `For` function + - this can be archieved by using the `For` function # Motivation [motivation]: #motivation @@ -76,7 +76,7 @@ Package sets often depend on the version of a base program, such as an interpret Package sets are sometimes nested: - `emacsPackages.{melpa,elpa,nongnu}{,Devel}Packages` - `ocamlPackages.janeStreet` -- `vscode-extensions.*` but thats a whole another mess +- `vscode-extensions.*` but that's a whole another mess - `kdePackages.{gear,frameworks,plasma}` - ... @@ -160,7 +160,7 @@ in ``` Package sets in `pkgs/sets` _must_ have a file `pkgs/sets//manual-packages.nix` -that is an overlay containing derivations outside of the `by-name` structure +that is an overlay containing derivations outside the `by-name` structure - **auto generated package sets** don't need to abuse the `overrides.nix` - the migration of (large) package sets can initially keep the `by-name` structure empty and only fill it gradually, simplifying the migration of large package sets @@ -174,8 +174,8 @@ Since the `packageset.nix` is not automatically called there is no need to place any more restrictions on this file, which allows package sets to be flexible. Calling these package sets should be done in a file in `pkgs/top-level` e.g. -- `top-level/package-sets.nix` -> have all package sets in one place -- `top-level/all-packages.nix` -> only have autocalled packages in a separate file -> file is small +- `top-level/package-sets.nix` → have all package sets in one place +- `top-level/all-packages.nix` → only have autocalled packages in a separate file → file is small If a package set does not have a `packageset.nix`, it is autocalled by a file in `pkgs/top-level` (e.g. `top-level/package-sets.nix`). @@ -183,7 +183,7 @@ it is autocalled by a file in `pkgs/top-level` (e.g. `top-level/package-sets.nix Versioned package sets like `python*Packages`, `nextcloud*Packages` will have to use the manual calling with `packageset.nix` -Example `packageset.nix` (i think this would work but i haven't tested it): +Example `packageset.nix` (I think this would work, but I haven't tested it): ```nix { lib, @@ -270,13 +270,13 @@ pkgs │ │ ├── aliases.nix │ │ ├── functions.nix │ │ ├── overrides.nix -│ │ └── packageset.nix <- entrypoint for versioned python3Packages +│ │ └── packageset.nix ← entrypoint for versioned python3Packages │ ... └── top-level - ├── by-name-overlay.nix <- aliases for deprecated versions of package sets - ├── by-name-overlay.nix <- used to autocall sharded packages (no change required) + ├── by-name-overlay.nix ← aliases for deprecated versions of package sets + ├── by-name-overlay.nix ← used to autocall sharded packages (no change required) ... - └── package-sets.nix <- calls all package sets in pkgs/sets + └── package-sets.nix ← calls all package sets in pkgs/sets ``` ## `pkgs/top-level/package-sets.nix` could look like From 09d1ce18d05163e02f280ebb22b02cb54abef0b7 Mon Sep 17 00:00:00 2001 From: quantenzitrone Date: Wed, 4 Mar 2026 12:23:41 +0100 Subject: [PATCH 26/31] fixes --- rfcs/0197-package-set-definitions.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/rfcs/0197-package-set-definitions.md b/rfcs/0197-package-set-definitions.md index 78cde2d5e..ebbd74dc5 100644 --- a/rfcs/0197-package-set-definitions.md +++ b/rfcs/0197-package-set-definitions.md @@ -202,6 +202,7 @@ lib.makeScope newScope ( (import ./overrides.nix) (import ./functions.nix) (import ./aliases.nix) + (import ./manual-packages.nix) ] ) ) @@ -247,6 +248,7 @@ pkgs │ │ │ └── package.nix │ │ ├── aliases.nix │ │ ├── functions.nix +│ │ ├── manual-packages.nix │ │ ├── mkFishPlugin.nix (could also be inlined in functions.nix) │ │ └── overrides.nix │ │ @@ -269,11 +271,12 @@ pkgs │ │ │ └── buildPythonPackage.nix │ │ ├── aliases.nix │ │ ├── functions.nix +│ │ ├── manual-packages.nix │ │ ├── overrides.nix │ │ └── packageset.nix ← entrypoint for versioned python3Packages │ ... └── top-level - ├── by-name-overlay.nix ← aliases for deprecated versions of package sets + ├── aliases.nix ← aliases for deprecated versions of package sets ├── by-name-overlay.nix ← used to autocall sharded packages (no change required) ... └── package-sets.nix ← calls all package sets in pkgs/sets @@ -307,6 +310,8 @@ lib.pipe ../sets [ )) # overlay functions (lib.extends (import (../sets/${name}/functions.nix))) + # overlay manual packages + (lib.extends (import (../sets/${name}/manual-packages.nix))) # overlay overrides (lib.extends (import (../sets/${name}/overrides.nix))) # make a new scope and recurse into it From 10bc6c94699c66b27f79564c3fba5d0dbb1f4aa6 Mon Sep 17 00:00:00 2001 From: quantenzitrone Date: Wed, 4 Mar 2026 12:26:07 +0100 Subject: [PATCH 27/31] more fixes --- rfcs/0197-package-set-definitions.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/rfcs/0197-package-set-definitions.md b/rfcs/0197-package-set-definitions.md index ebbd74dc5..81ca89261 100644 --- a/rfcs/0197-package-set-definitions.md +++ b/rfcs/0197-package-set-definitions.md @@ -188,6 +188,7 @@ Example `packageset.nix` (I think this would work, but I haven't tested it): { lib, newScope, + config, }: python: lib.makeScope newScope ( @@ -199,10 +200,13 @@ lib.makeScope newScope ( }) [ (import ../../top-level/by-name-overlay.nix ./by-name) - (import ./overrides.nix) + (lib.extends ( + self: super: + lib.optionalAttrs config.allowAliases (import (../sets/${name}/aliases.nix) self super) + )) (import ./functions.nix) - (import ./aliases.nix) (import ./manual-packages.nix) + (import ./overrides.nix) ] ) ) From 89ead355cb3693f431a610cd65c42cf9d12dde7e Mon Sep 17 00:00:00 2001 From: quantenzitrone Date: Wed, 4 Mar 2026 13:52:07 +0100 Subject: [PATCH 28/31] fix examples --- rfcs/0197-package-set-definitions.md | 13 +++++-------- 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/rfcs/0197-package-set-definitions.md b/rfcs/0197-package-set-definitions.md index 81ca89261..3bd7fe4fc 100644 --- a/rfcs/0197-package-set-definitions.md +++ b/rfcs/0197-package-set-definitions.md @@ -200,10 +200,7 @@ lib.makeScope newScope ( }) [ (import ../../top-level/by-name-overlay.nix ./by-name) - (lib.extends ( - self: super: - lib.optionalAttrs config.allowAliases (import (../sets/${name}/aliases.nix) self super) - )) + (self: super: lib.optionalAttrs config.allowAliases (import (./aliases.nix) self super)) (import ./functions.nix) (import ./manual-packages.nix) (import ./overrides.nix) @@ -309,8 +306,8 @@ lib.pipe ../sets [ (lib.extends (import ./by-name-overlay.nix ../sets/${name}/by-name)) # overlay aliases (lib.extends ( - self: super: - lib.optionalAttrs self.config.allowAliases (import (../sets/${name}/aliases.nix) self super) + setself: setsuper: + lib.optionalAttrs self.config.allowAliases (import (../sets/${name}/aliases.nix) setself setsuper) )) # overlay functions (lib.extends (import (../sets/${name}/functions.nix))) @@ -328,7 +325,7 @@ lib.pipe ../sets [ // { # python # we only recurse into the newest 2 python versions - python3PackagesFor = self.callPackage ../sets/python3Packages/packageset.nix {}; + python3PackagesFor = self.callPackage ../sets/python3Packages/packageset.nix { }; python311Packages = self.python3PackagesFor self.python311; python312Packages = self.python3PackagesFor self.python312; python313Packages = lib.recurseIntoAttrs (self.python3PackagesFor self.python313); @@ -339,7 +336,7 @@ lib.pipe ../sets [ pypy3Packages = pypy312Packages; # nextcloud - nextcloudPackagesFor = self.callPackage ../sets/nextcloudPackages/packageset.nix {}; + nextcloudPackagesFor = self.callPackage ../sets/nextcloudPackages/packageset.nix { }; nextcloud31Packages = self.nextcloudPackagesFor "31"; # idk if it works like this, this is an example nextcloud32Packages = self.nextcloudPackagesFor "32"; nextcloud33Packages = self.nextcloudPackagesFor "33"; From dd2218ead0defd526e91d9bcb0d35e31b57ac39c Mon Sep 17 00:00:00 2001 From: quantenzitrone Date: Wed, 4 Mar 2026 16:03:57 +0100 Subject: [PATCH 29/31] more example code fixes --- rfcs/0197-package-set-definitions.md | 18 +++++++----------- 1 file changed, 7 insertions(+), 11 deletions(-) diff --git a/rfcs/0197-package-set-definitions.md b/rfcs/0197-package-set-definitions.md index 3bd7fe4fc..f3c55e107 100644 --- a/rfcs/0197-package-set-definitions.md +++ b/rfcs/0197-package-set-definitions.md @@ -194,17 +194,13 @@ python: lib.makeScope newScope ( self: lib.fix ( - lib.extend - (x: { - inherit python; - }) - [ - (import ../../top-level/by-name-overlay.nix ./by-name) - (self: super: lib.optionalAttrs config.allowAliases (import (./aliases.nix) self super)) - (import ./functions.nix) - (import ./manual-packages.nix) - (import ./overrides.nix) - ] + lib.pipe (x: { inherit python; }) [ + (lib.extends (import ../../top-level/by-name-overlay.nix ./by-name)) + (lib.extends (self: super: lib.optionalAttrs config.allowAliases (import ./aliases.nix self super))) + (lib.extends (import ./functions.nix)) + (lib.extends (import ./manual-packages.nix)) + (lib.extends (import ./overrides.nix)) + ] ) ) ``` From 12a3811fc238f4b8a64200af42c13dca1d4cf2c5 Mon Sep 17 00:00:00 2001 From: quantenzitrone Date: Thu, 5 Mar 2026 15:03:41 +0100 Subject: [PATCH 30/31] make by-name non-mandatory since we can't have empty folders in git --- rfcs/0197-package-set-definitions.md | 22 +++++++++++++++++----- 1 file changed, 17 insertions(+), 5 deletions(-) diff --git a/rfcs/0197-package-set-definitions.md b/rfcs/0197-package-set-definitions.md index f3c55e107..636ee2e24 100644 --- a/rfcs/0197-package-set-definitions.md +++ b/rfcs/0197-package-set-definitions.md @@ -19,7 +19,7 @@ Package sets (definition see [Detailed Design](#detailed-design) e.g.`fishPlugin - variables like `version`, `withFoo`, ... - TBD: other package sets? - should move to `pkgs/sets/` where - - they must have a directory `pkgs/sets//by-name` + - they _may_ have a directory `pkgs/sets//by-name` with a sharded `by-name` like structure that is checked in the CI with `nixpkgs-vet` - packages in this structure will get all the benefits of `pkgs/by-name` @@ -105,12 +105,14 @@ with a few exceptions for versioned package sets that don't have a default versi - e.g. `nextcloud*Packages` will be in `pkgs/sets/nextcloudPackages`, but there is no `pkgs.nextcloudPackages` -Package sets in `pkgs/sets` _must_ have a directory `pkgs/sets//by-name` +Package sets in `pkgs/sets` _may_ have a directory `pkgs/sets//by-name` which is a sharded directory structure for isolated package definitions as defined by RFC 140. This sharded structure is checked in the CI by `nixpkgs-vet` and will get the same benefits of `pkgs/by-name` like merge bot maintainer merging, scaleability, isolation and vetting. -If there are no packages that fit into this structure, it may be empty. +The directory `by-name` is not mandatory because not all package sets +(e.g. completely generated package sets) have packages that fit into this structure. +It is impossible to have empty folders in git. Package sets in `pkgs/sets` _must_ have a file `pkgs/sets//overrides.nix` that is an overlay containing overrides for packages in the `by-name` structure @@ -195,7 +197,12 @@ lib.makeScope newScope ( self: lib.fix ( lib.pipe (x: { inherit python; }) [ - (lib.extends (import ../../top-level/by-name-overlay.nix ./by-name)) + (lib.extends ( + self: super: + lib.optionalAttrs (lib.pathExists ./by-name) ( + import ../../top-level/by-name-overlay.nix ./by-name self super + ) + )) (lib.extends (self: super: lib.optionalAttrs config.allowAliases (import ./aliases.nix self super))) (lib.extends (import ./functions.nix)) (lib.extends (import ./manual-packages.nix)) @@ -299,7 +306,12 @@ lib.pipe ../sets [ name: _: lib.pipe (self: { }) [ # autocall all sharded by name packages - (lib.extends (import ./by-name-overlay.nix ../sets/${name}/by-name)) + (lib.extends ( + self: super: + optionalAttrs (lib.pathExists ../sets/${name}/by-name) ( + import ./by-name-overlay.nix ../sets/${name}/by-name self super + ) + )) # overlay aliases (lib.extends ( setself: setsuper: From 5cc6e2b6f7d42143a75d2d2085146362886b4ad7 Mon Sep 17 00:00:00 2001 From: quantenzitrone Date: Thu, 5 Mar 2026 15:04:01 +0100 Subject: [PATCH 31/31] clarifications --- rfcs/0197-package-set-definitions.md | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/rfcs/0197-package-set-definitions.md b/rfcs/0197-package-set-definitions.md index 636ee2e24..3d81034e3 100644 --- a/rfcs/0197-package-set-definitions.md +++ b/rfcs/0197-package-set-definitions.md @@ -23,7 +23,7 @@ Package sets (definition see [Detailed Design](#detailed-design) e.g.`fishPlugin with a sharded `by-name` like structure that is checked in the CI with `nixpkgs-vet` - packages in this structure will get all the benefits of `pkgs/by-name` - - they must have files `overrides.nix`, `aliases.nix`, `functions.nix` and `manual-packages.nix` + - they _must_ have files `overrides.nix`, `aliases.nix`, `functions.nix` and `manual-packages.nix` containing aliases, overrides, functions and packages outside the `by-name` structure - are optionally are autocalled - this would be the case for manually defined package sets @@ -34,9 +34,9 @@ Package sets (definition see [Detailed Design](#detailed-design) e.g.`fishPlugin - can be versioned for which they: - are called multiple times through `packageset.nix` with the different interpreter/compiler/... versions - - may have a top-level function `For` that allows convenient creation + - _may_ have a top-level function `For` that allows convenient creation of new versions - - may be in `passthru` of the package that they depend on + - _may_ be in `passthru` of the package that they depend on - this can be archieved by using the `For` function # Motivation @@ -178,9 +178,13 @@ which allows package sets to be flexible. Calling these package sets should be done in a file in `pkgs/top-level` e.g. - `top-level/package-sets.nix` → have all package sets in one place - `top-level/all-packages.nix` → only have autocalled packages in a separate file → file is small +The `packageset.nix` is especially useful for versioned package set, +but could also be used for other package sets that need special handling. + If a package set does not have a `packageset.nix`, it is autocalled by a file in `pkgs/top-level` (e.g. `top-level/package-sets.nix`). +This would be the case for most simple or auto generated package sets. Versioned package sets like `python*Packages`, `nextcloud*Packages` @@ -212,14 +216,14 @@ lib.makeScope newScope ( ) ``` -Versioned package sets may define a top-level function wrapping this e.g. +Versioned package sets _may_ define a top-level function wrapping this e.g. ```nix { pythonPackagesFor = callPackage ../sets/pythonPackages/packageset.nix {}; } ``` -Versioned package sets may be in `passthru` of the package that they depend on e.g. +Versioned package sets _may_ be in `passthru` of the package that they depend on e.g. ```nix { lib,