In reply to @Ericson2314:matrix.org
did we have meeting today?

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.

In reply to @k900:conduit.0upti.me
That's getting dangerously close to packages-as-modules already tbh

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