The current advice of "keeping the override interface" is actively bad,
because it hides certain expectations of a package function in an
undiscoverable place. Ideally, all information about a package is in
one, single place instead.
Version-specific argument names, if required, also have the *benefit* of
creating errors with downstream overrides, much like merge conflicts do.
Instead of possibly silently breaking certain behavior, they make a
change in expectations clear - which might feel annoying when upgrading,
but is ultimately much less problematic down the road.
Since this original guideline has been written, the new
nixpkgs-merge-bot has appeared, and depends on packages being in
`pkgs/by-name`. It's totally fine to move packages for that purpose
only.
Also update the guidelines to indicate that it might take some time
still for the automated migration to be completed.
Everything gets moved into the `ci/` top-level directory.
We keep behind `maintainers/scripts/check-by-name.sh` and `pkgs/test/check-by-name/pinned-version.txt` as they are going to cause CI errors and confusion until we get all the way through the various channels.
They'll be removed in about a week or so.
Over the past weeks, we've seen one oversight with the new
enforcement of `pkgs/by-name` for new packages.
This documents the problem and the recommendation for resolving it.
Due to the check soon depending on the base branch (see `--base`),
the CI check can't reasonably share all code with a local check.
We can still make a script to run it locally, just not sharing all code.
This introduces the `pkgs/by-name` directory as proposed by RFC 140.
Included are:
- The implementation to add packages defined in that directory to the
top-level package scope
- Contributer documentation on how to add packages to it
- A GitHub Actions workflow to check the structure of it on all PRs
