stdenv/check-meta: add a warning for maintainerless derivations

[ckiee]

Description of changes

This makes stdenv.mkDerivation emit warnings when a package does not
have any maintainers in order to encourage these core packages to be adopted.

Evaluating pkgs.hello currently results in 12 warnings, demonstrating
the need for this.

This behavior is gated behind a showDerivationWarnings nixpkgs config option
to reduce unnecessary output for end users.

Example output:

ckie@cookiemonster ~/git/nixpkgs -> nix-build --expr '(import ./. { config = {showDerivationWarnings = true;};}).hello'
trace: Package ed-1.18 in /home/ckie/git/nixpkgs/pkgs/applications/editors/ed/default.nix:23 has no maintainers, continuing anyway.
trace: Package patch-2.7.6 in /home/ckie/git/nixpkgs/pkgs/tools/text/gnupatch/default.nix:44 has no maintainers, continuing anyway.
[...]
/nix/store/g124820p9hlv4lj8qplzxw1c44dxaw1k-hello-2.12

cc @lheckemann, thanks for the idea.

TODO

• Figure out why a warning for python3-minimal-3.9.12 is emitted even though it does have a maintainer Not block-worthy
• Add a way to suppress warnings?

[vcunat]

I don't know... this approach feels too annoying. Just look at the hello example. It's very trivial package, but there already you get warnings for many packages that intuitively don't much relate to the package. Also, it will bother on every evaluation, i.e. any time it's used; that's just not useful IMHO.

[vcunat]

Maybe in some far-away future when the maintainers field is used very differently than nowadays. Another common issue is that one or more maintainers are listed but none has done anything around the package for years.

[mohe2015]

Maybe instead we could add some easy way that allows you to enable this if you want. So you can easily check your own derivations. Dont know how to do this exactly though

[ckiee]

Maybe instead we could add some easy way that allows you to enable this if you want. So you can easily check your own derivations. Dont know how to do this exactly though (~@mohe2015)

I've now gated this behind a new showDerivationWarnings config option:

ckie@cookiemonster ~/git/nixpkgs -> nix-build --expr '(import ./. { config = {showDerivationWarnings = true;};}).hello'
trace: Package python3-minimal-3.9.10 in /home/ckie/git/nixpkgs/pkgs/development/interpreters/python/cpython/default.nix:491 has no maintainers, continuing anyway.
[..snip..]
/nix/store/g124820p9hlv4lj8qplzxw1c44dxaw1k-hello-2.12

I don't know... this approach feels too annoying. Just look at the hello example. It's very trivial package, but there already you get warnings for many packages that intuitively don't much relate to the package. Also, it will bother on every evaluation, i.e. any time it's used; that's just not useful IMHO.

Well, if we want to get closer to addressing the considerable amount of orphans we need something like this.

Maybe in some far-away future when the maintainers field is used very differently than nowadays. Another common issue is that one or more maintainers are listed but none has done anything around the package for years.

Strawman? Addressing everything in one PR is not feasible.

[roberth]

Please add to pkgs/top-level/config.nix.

See #166792 #171163

[ckiee]

(@roberth)

Would you be open to a PR that documents all the other missing options I can think of, or is that already in the works?

[roberth]

@ckiee I don't really have time for "big" projects, so that would be very much appreciated.

[Artturin]

i'll add allowUnfree there

EDIT: #171248

[SuperSandro2000]

Turning that on right now.

[Mindavi]

Not sure about the valid changes mixed in here. But the warning for missing maintainers sounds like it could be useful for people interested in that. Personally I'm not looking forward to a wall of warnings, but I guess others may be.

Please at least split the valid change into a different commit, and reconsider making a separate PR for it.

[ckiee]

Not sure about the valid changes mixed in here.

valid is not exposed as a public API and breaking the one other relevant open PR seems unlikely and is not a blocker regardless. Hence this is a moot point.

Please at least split the valid change into a different commit, and reconsider making a separate PR for it.

I'm afraid you're a bit late for a separate PR (note how far this one has gone already) but I have split it into three commits with nicer, more detailed commit messages.

Also I just noticed there's merge conflicts again, on that.

[Mindavi]

Good enough for me, thanks ✨ :

[ckiee]

@Mindavi Merge after Ofborg's happy?