From 67332417ab903aa71cb36ed6c6bbe685f45209f8 Mon Sep 17 00:00:00 2001 From: quantenzitrone Date: Sun, 23 Nov 2025 23:01:15 +0100 Subject: [PATCH 1/5] rfc 192: first revision --- rfcs/0192-by-name-version-pins.md | 109 ++++++++++++++++++++++++++++++ 1 file changed, 109 insertions(+) create mode 100644 rfcs/0192-by-name-version-pins.md diff --git a/rfcs/0192-by-name-version-pins.md b/rfcs/0192-by-name-version-pins.md new file mode 100644 index 0000000..968961d --- /dev/null +++ b/rfcs/0192-by-name-version-pins.md @@ -0,0 +1,109 @@ +--- +feature: by-name-version-pins +start-date: 2025-11-25 +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: https://github.com/NixOS/nixpkgs/pull/464396 +--- + +# Summary +[summary]: #summary + +Add an additional file `pins.nix` to the `pkgs/by-name` structure that allows overriding/pinning +package versions. + +# Motivation +[motivation]: #motivation + +> Why are we doing this? + +- The `pkgs/by-name` structure doesn't have support for overriding packages yet + leading to a lot of remaining entries in `pkgs/top-level/all-packages.nix`. +- Packages with version pins often get neglected and stay on the old version + for a long time, even though it already supports the new version. By having + version pins in a defined location with a defined structure, package update + bots or scripts could check if the package works without the pin and remove it + automatically on update. + +> What use cases does it support? + +- Pinning package versions of packages. + +> What is the expected outcome? + +- Less confusion if package pins should go into `all-packages.nix` or be inlined + in the `package.nix`. +- Less maintenance burden due to possible automation of pin removal. + +# Detailed design +[design]: #detailed-design + +In addition to `pkgs/by-name/{shard}/{pname}/package.nix` there can also be +`pkgs/by-name/{shard}/{pname}/pins.nix`. This file will have the following structure: + +```nix +{ + package-a_version, + package-b_version, + # [...] +}: +{ + package-a = package-a_version; + package-b = package-b_version; + # [...] +} +``` + +- Every attrName in the resulting attribute set has to be a valid package + attribute name. +- Every attrValue should be the pinned version of the respectice attrName + package, this is however hard to check I think. +- Every attrName has to be a functionArg of the `package.nix`. + +I think you know where this is going. + +Packages with a `pin.nix` will have the versions of packages pinned +accordingly. This can be easily archived with: + +```nix +if lib.pathExists (packageDirectory + "/pins.nix") then + callPackage (packageDirectory + "/package.nix") ( + lib.removeAttrs (callPackage (packageDirectory + "/pins.nix") { }) [ + "override" + "overrideDerivation" + ] + ) +else + callPackage (packageDirectory + "/package.nix") +``` + +# Examples and Interactions +[examples-and-interactions]: #examples-and-interactions + +# Drawbacks +[drawbacks]: #drawbacks + +Probably longer eval time, this has to be tested however. + +# Alternatives +[alternatives]: #alternatives + +- Keep the current situation: version pins are either in `all-packages.nix` or + directly in the `package.nix`. +- Some more generalized `overrides.nix` without the strict requirements. +- Your suggestion here. + +# Prior art +[prior-art]: #prior-art + +- [RFC 140](https://github.com/NixOS/rfcs/blob/master/rfcs/0140-simple-package-paths.md) + lists the problem this RFC is trying to solve under "Future work". + +# Unresolved questions +[unresolved]: #unresolved-questions + +# Future work +[future]: #future-work + From dd79622dac19da0a241bcc4548d9ea3d3e9eec10 Mon Sep 17 00:00:00 2001 From: Zitrone <74491719+quantenzitrone@users.noreply.github.com> Date: Mon, 24 Nov 2025 11:44:12 +0000 Subject: [PATCH 2/5] Update rfcs/0192-by-name-version-pins.md Co-authored-by: Michael Daniels --- rfcs/0192-by-name-version-pins.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/0192-by-name-version-pins.md b/rfcs/0192-by-name-version-pins.md index 968961d..11dc984 100644 --- a/rfcs/0192-by-name-version-pins.md +++ b/rfcs/0192-by-name-version-pins.md @@ -65,7 +65,7 @@ In addition to `pkgs/by-name/{shard}/{pname}/package.nix` there can also be I think you know where this is going. Packages with a `pin.nix` will have the versions of packages pinned -accordingly. This can be easily archived with: +accordingly. This can be easily achieved with: ```nix if lib.pathExists (packageDirectory + "/pins.nix") then From f6d34a773ec37ba196c1f635ae3464586c5526b5 Mon Sep 17 00:00:00 2001 From: quantenzitrone Date: Wed, 26 Nov 2025 17:58:47 +0100 Subject: [PATCH 3/5] clarify that this rfc is about pinning dependencies and not the packages itself --- rfcs/0192-by-name-version-pins.md | 37 ++++++++++++++++--------------- 1 file changed, 19 insertions(+), 18 deletions(-) diff --git a/rfcs/0192-by-name-version-pins.md b/rfcs/0192-by-name-version-pins.md index 11dc984..fac2c6f 100644 --- a/rfcs/0192-by-name-version-pins.md +++ b/rfcs/0192-by-name-version-pins.md @@ -11,8 +11,8 @@ related-issues: https://github.com/NixOS/nixpkgs/pull/464396 # Summary [summary]: #summary -Add an additional file `pins.nix` to the `pkgs/by-name` structure that allows overriding/pinning -package versions. +Add an additional file `pins.nix` to the `pkgs/by-name` structure that allows +overriding/pinning versions of package dependencies. # Motivation [motivation]: #motivation @@ -21,20 +21,20 @@ package versions. - The `pkgs/by-name` structure doesn't have support for overriding packages yet leading to a lot of remaining entries in `pkgs/top-level/all-packages.nix`. -- Packages with version pins often get neglected and stay on the old version - for a long time, even though it already supports the new version. By having - version pins in a defined location with a defined structure, package update - bots or scripts could check if the package works without the pin and remove it - automatically on update. +- Packages with dependency version pins often get neglected and stay on the old + version for a long time, even though it already supports the new version. By + having dependency version pins in a defined location with a defined structure, + package update bots or scripts could check if the package works without the + pin and remove it automatically on update. > What use cases does it support? -- Pinning package versions of packages. +- Pinning dependency versions of packages. > What is the expected outcome? -- Less confusion if package pins should go into `all-packages.nix` or be inlined - in the `package.nix`. +- Less confusion if dependency pins should go into `all-packages.nix` or be + inlined in the `package.nix`. - Less maintenance burden due to possible automation of pin removal. # Detailed design @@ -47,12 +47,12 @@ In addition to `pkgs/by-name/{shard}/{pname}/package.nix` there can also be { package-a_version, package-b_version, - # [...] + # ... }: { package-a = package-a_version; package-b = package-b_version; - # [...] + # ... } ``` @@ -64,19 +64,20 @@ In addition to `pkgs/by-name/{shard}/{pname}/package.nix` there can also be I think you know where this is going. -Packages with a `pin.nix` will have the versions of packages pinned +Packages with a `pin.nix` will have the versions of dependencies pinned accordingly. This can be easily achieved with: ```nix if lib.pathExists (packageDirectory + "/pins.nix") then - callPackage (packageDirectory + "/package.nix") ( - lib.removeAttrs (callPackage (packageDirectory + "/pins.nix") { }) [ + let + pins = lib.removeAttrs (callPackage (packageDirectory + "/pins.nix") { }) [ "override" "overrideDerivation" - ] - ) + ]; + in + callPackage (packageDirectory + "/package.nix") pins else - callPackage (packageDirectory + "/package.nix") + callPackage (packageDirectory + "/package.nix") { } ``` # Examples and Interactions From b0c20094f2bdbe9e428b87fd6b220d11fb7415b2 Mon Sep 17 00:00:00 2001 From: quantenzitrone Date: Wed, 26 Nov 2025 18:00:18 +0100 Subject: [PATCH 4/5] add pinning versions of packages themselves under future work --- rfcs/0192-by-name-version-pins.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/rfcs/0192-by-name-version-pins.md b/rfcs/0192-by-name-version-pins.md index fac2c6f..972af7d 100644 --- a/rfcs/0192-by-name-version-pins.md +++ b/rfcs/0192-by-name-version-pins.md @@ -108,3 +108,5 @@ Probably longer eval time, this has to be tested however. # Future work [future]: #future-work +- pinning versions of packages, e.g. having ffmpeg_7 as a subattribute of ffmpeg + (not dependency pinning, what this rfc is about) From 8add3b0effc49cc3656f173431d268597432268d Mon Sep 17 00:00:00 2001 From: quantenzitrone Date: Wed, 26 Nov 2025 18:00:39 +0100 Subject: [PATCH 5/5] add more alternatives --- rfcs/0192-by-name-version-pins.md | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/rfcs/0192-by-name-version-pins.md b/rfcs/0192-by-name-version-pins.md index 972af7d..ed3dff8 100644 --- a/rfcs/0192-by-name-version-pins.md +++ b/rfcs/0192-by-name-version-pins.md @@ -93,7 +93,36 @@ Probably longer eval time, this has to be tested however. - Keep the current situation: version pins are either in `all-packages.nix` or directly in the `package.nix`. + - Some more generalized `overrides.nix` without the strict requirements. + - This would be less useful for automation of dependency pin removal. + +- Inline dependency pins in `package.nix` as default values in the function arguments. + ```nix + { + package-a_version, + package-a ? package-a_version, + # ... + }: + # ... + ``` + This would require a custom `callPackage` for `pkgs/by-name` that prefers default values over + values from the `pkgs`. + - Confusing for contributors if something works differently through the normal `callPackage`. + +- Inline dependency pins in `package.nix` with `let in` syntax. + ```nix + { + package-a_version, + # ... + }: + let + package-a = package-a_version; + in + # ... + ``` + - Possibly harder to automate dependency pin removal. + - Your suggestion here. # Prior art