In reply to @piegames:matrix.org
Also, that's a lot of magic code and boilerplate, even for Nix' standards

In reply to @piegames:matrix.org
infinisil: I'd like to see the first RFC 140 implementation PR ready for being merged soon, if possible

In reply to @profpatsch:augsburg.one
k900: you can’t have packages as modules, it would kill performance even more

In reply to @adis:blad.is

Have anyone else thought of restructuring how we use stdenv.mkDerivation like this before?

let
  # Boilerplate import, not interesting.
  pkgs = import <nixpkgs> { };
  inherit (pkgs) stdenv lib;
  src = pkgs.hello.src;  # Just some random sources to showcase the idea

  # An example of how to possibly structure derivations such as they can be fully overrideable through overrideAttrs
  example = stdenv.mkDerivation (finalAttrs: {
    # Arguments are no longer arguments to to the function that returns the derivation
    # they are instead in passthru so they compose.
    #
    # You could also add a type system on top of this (yants/NixOS module system types)
    # so derivation arguments are introspectable in a standardised way.
    passthru.args = {
      pname = "example";
      version = "0.1.0";
      withCrypto = false;
    };

    # Inputs might be overridable in the same way.
    passthru.inputs = {
      inherit src;
      inherit (pkgs) openssl;
    };

    # This is a bit awkward for now..
    inherit (finalAttrs.passthru.args) pname version;
    inherit (finalAttrs.passthru.inputs) src;
    buildInputs = lib.optional finalAttrs.passthru.args.withCrypto finalAttrs.passthru.inputs.openssl;
  });

in

example.overrideAttrs (oldAttrs: {
  passthru = oldAttrs.passthru // {
    args = oldAttrs.passthru.args // {
      withCrypto = true;
    };
  };
})

This strikes me as a more concise way and would leave us with one blessed way to override regardless of context.
It would also be more introspectable than function args which are currently mixed between build configuration and build inputs.

I haven't thought too much about this yet and it might be a bad idea.

adisbladis: I had not thought of using the final as the source for the input, but S.O.S. is kind of layed out this way. With the same disadvantage that the update operator is becoming overwhelmingly present. I think this is part of the solution, except that as mkDerivation is still present. Thus you still need overrideAttrs to modify its argument.

To which the solution is simply to let people override whatever they want before applying mkDerivation at the very last moment.

In reply to @k900:conduit.0upti.me
removeAttrs is useful in other contexts