The Haskell Hydra report generator
(`maintainers/scripts/haskell/hydra-report.hs`) uses this
`maintainer-handles.nix` script for generating a mapping of email
addresses to GitHub handles.
This `maintainer-handles.nix` script is necessary because the Haskell
Hydra report generator gets Hydra job status info as input, but needs to
ping users on GitHub. Hydra job status info only contains user emails (not
GitHub handles). So the `maintainer-handles.nix` script is necessary
for looking up GitHub handles from email addresses.
This commit fixes the `maintainers-handles.nix` code to ignore
maintainers that don't have email addresses. The code was originally
assuming that all maintainers have email addresses, but there was
recently a maintainer added without an email address.
The name should end in Array per the current conventions.
This change also contains some minor formatting fixes, as the heading
levels were inconsistent.
Previously, unless unsupported platforms were allowed, the following
would fail to evaluate (from an "x86_64-linux" system):
pkgsCross.x86_64-freebsd.__splicedPackages.docutils.__spliced.buildHost
It shouldn't have, because the buildHost package ends up being for
Linux. This broke evaluation of e.g. pkgsCross.x86_64-freebsd.libdrm,
because it has docutils in nativeBuildInputs. mkDerivation would try
to go through __spliced.buildHost on docutils to get to the Linux
version, but the check in ensurePythonModules would kick in first,
triggering the meta check because of the equality check in the
implementation of hasPythonModule, which would fail because Python is
not marked as supported on FreeBSD in Nixpkgs at the moment. Thus,
even though they're not supposed to be, the meta checks would be
triggered even though the only attribute being accessed on the
unsupported derivation was __spliced.
We can fix this by using the same mechanism used to implement the meta
checks themselves: lib.extendDerivation. Now, attempting to access
drvPath or outPath on an attribute that fails the validity check will
produce the same error as before, but other accesses will be allowed
through, fixing splicing.
I've tested evaluation of packages that pass and fail the validity
check, and confirmed that the behaviour is still correct.
It wasn't clear before, but it turns out that this is just four
separate conditions, and an attribute is valid if any of the
conditions is true, so we don't need a sea of parentheses to express
it.
