From 4c4607fa6ba997aa6d8703dd7062dfd3a1dd07fb Mon Sep 17 00:00:00 2001 From: Frederik Rietdijk Date: Tue, 17 Mar 2020 12:51:05 +0100 Subject: [PATCH 1/5] Common override interface --- rfcs/0067-common-override-interface.md | 72 ++++++++++++++++++++++++++ 1 file changed, 72 insertions(+) create mode 100644 rfcs/0067-common-override-interface.md diff --git a/rfcs/0067-common-override-interface.md b/rfcs/0067-common-override-interface.md new file mode 100644 index 000000000..622052ebb --- /dev/null +++ b/rfcs/0067-common-override-interface.md @@ -0,0 +1,72 @@ +--- +feature: common-override-interface +start-date: 2020-03-17 +author: Frederik Rietdijk +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 + +Define commonly used attributes for overriding in Nixpkgs. + +# Motivation +[motivation]: #motivation + +In Nixpkgs several methods exist to override functions calls. The primary ones are: + +1. `.override` to override, typically, the first function call. +2. `.overrideAttrs` to override the call to `stdenv.mkDerivation`. +3. `.overrideDerivation` to override the call to `derivation`. + +The first two are mainly used and are typically sufficient. However, how can we override generic package builders, such as `buildPythonPackage` and `buildGoPackage`? + +For the `buildPythonPackage` function the `.overridePythonAttrs` was introduced that would override the call to `buildPythonPackage` because using `.overrideAttrs` would often not result in what the user expect would happen. In hindsight, it would have been better to attach a custom `.overrideAttrs` to `buildPythonPackage`. + +This RFC thus proposes to let generic builders define a custom `.overrideAttrs` that overrides the call to the generic builder. + +# Detailed design +[design]: #detailed-design + +The method `.overrideAttrs` will be modified so that instead of + +- `.overrideAttrs` to override the call to `stdenv.mkDerivation`. + +it will be + +- `.overrideAttrs` to override the call to the generic builder. + +The generic builders such as `buildGoPackage` would thus apply the function `makeOverridable` to it. + +In case of Python that already has `.overridePythonAttrs`, support for +```nix +buildGoPackage = makeOverridable buildGoPackage; +``` + +# Examples and Interactions +[examples-and-interactions]: #examples-and-interactions + +- + +# Drawbacks +[drawbacks]: #drawbacks + +After invoking a generic builder it is no longer possible to override the call to `stdenv.mkDerivation`. + +# Alternatives +[alternatives]: #alternatives + +An alternative would be to add a new method for overriding, `.overrideArgs`, thus allowing one to still call `.overrideAttrs` to override `stdenv.mkDerivation`. + +# Unresolved questions +[unresolved]: #unresolved-questions + +- + +# Future work +[future]: #future-work + +Implement the custom `.overrideAttrs` for the generic builders. From b5731e68a0b32b94dff3519ef2c46b840d309eca Mon Sep 17 00:00:00 2001 From: Frederik Rietdijk Date: Wed, 1 Jul 2020 07:34:56 +0200 Subject: [PATCH 2/5] scope: clarify this RFC is about derivations and not package sets. --- ...=> 0067-common-override-interface-derivations.md} | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) rename rfcs/{0067-common-override-interface.md => 0067-common-override-interface-derivations.md} (82%) diff --git a/rfcs/0067-common-override-interface.md b/rfcs/0067-common-override-interface-derivations.md similarity index 82% rename from rfcs/0067-common-override-interface.md rename to rfcs/0067-common-override-interface-derivations.md index 622052ebb..8b352f9da 100644 --- a/rfcs/0067-common-override-interface.md +++ b/rfcs/0067-common-override-interface-derivations.md @@ -1,5 +1,5 @@ --- -feature: common-override-interface +feature: common-override-interface-derivations start-date: 2020-03-17 author: Frederik Rietdijk co-authors: (find a buddy later to help out with the RFC) @@ -11,7 +11,7 @@ related-issues: (will contain links to implementation PRs) # Summary [summary]: #summary -Define commonly used attributes for overriding in Nixpkgs. +Define commonly used attributes for overriding of derivations in Nixpkgs. # Motivation [motivation]: #motivation @@ -22,7 +22,13 @@ In Nixpkgs several methods exist to override functions calls. The primary ones a 2. `.overrideAttrs` to override the call to `stdenv.mkDerivation`. 3. `.overrideDerivation` to override the call to `derivation`. -The first two are mainly used and are typically sufficient. However, how can we override generic package builders, such as `buildPythonPackage` and `buildGoPackage`? +Also used in several places but out of scope for this RFC because it is for +overriding package sets is `lib.overrideScope'`. + +The first two are mainly used and are typically sufficient. The third one should +typically be avoided and can be considered legacy. + +However, how can we override generic package builders, such as `buildPythonPackage` and `buildGoPackage`? For the `buildPythonPackage` function the `.overridePythonAttrs` was introduced that would override the call to `buildPythonPackage` because using `.overrideAttrs` would often not result in what the user expect would happen. In hindsight, it would have been better to attach a custom `.overrideAttrs` to `buildPythonPackage`. From 7e605a94237f2663ec3751db17eb0fdc1842e5ab Mon Sep 17 00:00:00 2001 From: Frederik Rietdijk Date: Wed, 1 Jul 2020 07:47:40 +0200 Subject: [PATCH 3/5] Scope: clarify the motivation for using a single `.overrideAttrs` is UI --- rfcs/0067-common-override-interface-derivations.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/rfcs/0067-common-override-interface-derivations.md b/rfcs/0067-common-override-interface-derivations.md index 8b352f9da..63d80a812 100644 --- a/rfcs/0067-common-override-interface-derivations.md +++ b/rfcs/0067-common-override-interface-derivations.md @@ -11,7 +11,8 @@ related-issues: (will contain links to implementation PRs) # Summary [summary]: #summary -Define commonly used attributes for overriding of derivations in Nixpkgs. +Define commonly used attributes for overriding of derivations in Nixpkgs to +improve overriding from a UI point of view. # Motivation [motivation]: #motivation From 252ff3ec4751726d8ea71a868ef5de9acdd54ae5 Mon Sep 17 00:00:00 2001 From: Frederik Rietdijk Date: Wed, 1 Jul 2020 07:47:47 +0200 Subject: [PATCH 4/5] Extend alternatives --- ...7-common-override-interface-derivations.md | 22 ++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/rfcs/0067-common-override-interface-derivations.md b/rfcs/0067-common-override-interface-derivations.md index 63d80a812..3420d6ae9 100644 --- a/rfcs/0067-common-override-interface-derivations.md +++ b/rfcs/0067-common-override-interface-derivations.md @@ -66,7 +66,27 @@ After invoking a generic builder it is no longer possible to override the call t # Alternatives [alternatives]: #alternatives -An alternative would be to add a new method for overriding, `.overrideArgs`, thus allowing one to still call `.overrideAttrs` to override `stdenv.mkDerivation`. +An alternative would be to let generic builders add their own methods, e.g. +`overridePythonAtrrs`, `overrideGoAttrs`, and so on. While it may be clear which +function it overrides, the user may not actually know what functions are called +and thus may not know which override to use. From a UI point of view, they +should probably not even need to know; all they should know is that there is a +method which, when called, will apply what is expected. + +An alternative would be to add a new method for overriding of generic builders, +`.overrideArgs`, thus allowing one to still call `.overrideAttrs` to override +`stdenv.mkDerivation`. This is a new function users may need to be aware of. +From a UI point of view, it could mean `stdenv.mkDerivation`, when not wrapped +into a generic builder, may also need to offer `.overrideAttrs` for consistency. + +An alternative would be to have a generic override function that can override +any function in the stack of function calls. E.g. +- `.override` becomes `.overrideCall "callPackage" { ... }` +- `.overrideAttrs becomes .overrideCall "mkDerivation" { ... }` +- `.overridePythonAttrs becomes .overrideCall "buildPythonPackage" { ... }` +- `.overrideDerivation becomes .overrideCall "derivation" { ... }` +While this offers maximum precision when overriding, this does not solve the UI +problem either. # Unresolved questions [unresolved]: #unresolved-questions From 3e5452ea6694ffc667e6db88fc34c246bd4cc26b Mon Sep 17 00:00:00 2001 From: Linus Heckemann Date: Thu, 24 Sep 2020 15:18:21 +0200 Subject: [PATCH 5/5] Add shepherd metadata --- rfcs/0067-common-override-interface-derivations.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/rfcs/0067-common-override-interface-derivations.md b/rfcs/0067-common-override-interface-derivations.md index 3420d6ae9..e07fc5276 100644 --- a/rfcs/0067-common-override-interface-derivations.md +++ b/rfcs/0067-common-override-interface-derivations.md @@ -3,8 +3,8 @@ feature: common-override-interface-derivations start-date: 2020-03-17 author: Frederik Rietdijk 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) +shepherd-team: @Infinisil, @edolstra, @Taneb, @7c6f434c +shepherd-leader: @Infinisil related-issues: (will contain links to implementation PRs) ---