This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/misuse-of-commit-permissions/10071/38

So we had a short meeting on this RFC where everybody but @fpletz was present. To call out the FCP we want the following things to be updated in the RFC:

The following two core ideas in the RFC should stay:

• Use settings options/free form options instead of extraConfig
• don't introduce too many options for every possible configuration.

Instead of the proposed implementation it should now link to the nixpkgs manual that describe free form modules.

Squashed the edits until now. Seems to have helped.

Making some minor tweaks to how phases are run in the stdenv to improve the UX of nix-shell.

Rendered view: https://github.com/dezgeg/rfcs/blob/phase-changes/rfcs/0032-run-phase-changes-for-better-nix-shell-use.md

So this RFC has the following shepherd: @FRidh, @lheckemann, @edolstra. Thanks!

Nominating myself as a shepherd.

@Profpatsch would you be interested in being a shepherd on this RFC?

Generally this RFC is in need for more shepherds before being able to move onwards.

For some reason 0072-commonmark-docs.md is part of this RFC, could you remove it?

Potential use case: https://github.com/ttacon/glorious/issues/49 / https://github.com/numtide/devshell/issues/47

Meeting 1

Present were @FRidh, @7c6f434c, @Taneb and @Infinisil

Notes

Which override functions do people actually use?

• sometimes (Haskell) you need to override source in mkDerivation and not in the builder
• user UI: is knowledge of correct overrides needed?
  • ask for overriding the expression you see
  • but still need to understand the semantics

Stack of overridable things, e.g. for python:

• .override for callPackage
• .overridePythonAttrs for buildPythonPackage
• .overrideAttrs for mkDerivation
• .overrideDerivation for derivation

We don't want to conflate overrides of different layers with each other. Each override function should be for its specific function. Having .overrideAttrs override buildPythonPackage arguments would cross layers

To unify these layers we could give string names to each layer

• .overrideLayer "layerName" overrides arguments of the given layer
• This .overrideLayer function can make sure that all the other layer overrides get updated as well (no more complexity of this in each override function declaration)

With this in place, it might be possible to create a layer-inferencing override mechanism

• .overrideLayerAuto applies attributes to the layer they are inferred from
• This allows users to not have to know the implementation details anymore to know how things can be overridden
• If the layer inference turns out to be ambiguous, throw an error telling the user to use .overrideLayer "<name>" instead

With this, we could also add smarts around function arguments

• Each layer could add description values to arguments, which document their use
• For ambiguous overrides, these descriptions are displayed
• Can also declare supersedes-like relation, where e.g. the buildInputs of mkDerivation supersedes the buildInputs of derivation, therefore not triggering an ambiguity error

Should these overrides be a library function like lib.overrideLayer instead?

• Doing this might allow Nix to collect Nix values which previously were kept around
• We could also make it backwards compatible by aliasing .overrideLayer to lib.overrideLayer

Conclusions:

• Let's not shadow .overrideAttrs arguments with .overridePythonAttrs
• Builders may have their own override, as it mirrors the .overrideLayer approach, and we can introduce aliases later
• However, it's very tricky to properly implement such custom .overrideFooAttrs functions, as these need to be aware of any other layers and override them all