`setup.sh` Developer Experience

[roberth]

Issue description

Working on setup.sh is pretty awful. Unless you cobble together your own workflow for it, it looks like

1. make a tiny change
2. mass-rebuild

This iteration cycle is longer than it needs to be and makes adequate testing practically infeasible to the point where we don't do it.

Goal

Before doing significant work on setup.sh I think we should pay attention to the developer experience.

Describe when this issues should be considered done

• [ ] a way to try override setup.sh for a single derivation, to allow experimentation (shortest feedback cycle while working on the implementation)
• [ ] beginnings of a test suite, so that we don't need to build all of nixpkgs to exercise typical corner cases, and so that TDD is viable
• [ ] a section in the Nixpkgs manual with some hints on how to hack on this. A README in its directory might be an alternative.

[Artturin]

a way to try override setup.sh for a single derivation, to allow experimentation (shortest feedback cycle while working on the implementation)

https://github.com/NixOS/nixpkgs/blob/0446732359536566de33d8893bd4c682174e31e2/pkgs/stdenv/adapters.nix#L45-L53

  # Override the setup script of stdenv.  Useful for testing new
  # versions of the setup script without causing a rebuild of
  # everything.
  #
  # Example:
  #   randomPkg = import ../bla { ...
  #     stdenv = overrideSetup stdenv ../stdenv/generic/setup-latest.sh;
  #   };
  overrideSetup = stdenv: setupScript: stdenv.override { inherit setupScript; };

or stdenv.override { setupScript = ./pkgs/stdenv/generic/setup.sh; }