all-packages.nix: move defaults to package files

[oxij]

What?

A bit of noop cleanups followed by a first patchset in a series that moves package option defaults (like whateverSupport = false) from all-packages.nix to the package expressions themselves.

I take specific care not to rename or drop any config options here (I do add some as a side-effect, though).

Why?

Because definitions in all-packages.nix and package expression frequently conflict. It also makes #50643 (which itself is motivated by a proper implementation of #12877) much easier to do.

git log

• dwm: cleanup whitespace

• dysnomia: cleanup whitespace

• pulseaudioFull, libpulseaudio-vanilla: cleanup

  These are already inherited in the parent derivation.

• top-level: fix a typo

• top-level: cleanup whitespace

• lib: tiny cleanup

• *: move defaults to the package file

A bunch of these.

nix-instantiate environment

• Host OS: Linux 4.9, SLNOS 19.03
• Nix: nix-env (Nix) 2.1.3
• Multi-user: yes
• Sandbox: yes
• NIXPKGS_CONFIG:

{
  checkMeta = true;
  doCheckByDefault = true;
}

nix-env -qaP diffs

• On x86_64-linux: noop
• On aarch64-linux: noop
• On x86_64-darwin: noop

/cc @matthewbauer @7c6f434c, I guess

[7c6f434c]

Shoud this openssh ? null become just openssh if the local default for ssh support is true?

[oxij]

In theory: no preference, in practice: it usually it is not in most other expressions.

[7c6f434c]

The default will have the openssh argument, so getting null already needs an explicit override, no?

[oxij]

Strictly speaking, the default it will get depends on callPackage implementation used, so the above should be okay, normally. In this instance, however, the output will depend on openssh anyway because the path gets burned into derivation irrespective of sshSupport. I'm not sure if fixing this should be in scope of this PR, though.

[7c6f434c]

I was only asking about default argument values, I agree with both your implied claims (ignoring the argument if the support if off is good, but fixing this is out of scope).

I think if it is called in Nixpkgs exactly once, it is acceptable to assume this is the only type of callPackage that will be applied.

[7c6f434c]

Somewhat borderline on that… (I do not oppose that, but do not actively suport and will wait longer for objections to this change before merging)

[oxij]

But that is exactly what was written in all-packages.nix before this change.

[7c6f434c]

I agree with the logic, I am just not sure if this type of extracting defaults from contents of other arguments is something everyone has made peace with.

[oxij]

Hm, I felt this was a common thing to do, grep -rE '.*Support \? .*Support' gives a lot of results.

[7c6f434c]

I tried to comment on the entire two-line combo — …Support ? …Support but together with …Support ? config.…

[oxij]

Ah, I see. Well, a) it is just another variable binding, so not that much of a difference, IMHO b) I don't see any other options in this case as applying config.ghostscript or {} in all-packages.nix will do the wrong thing.

[7c6f434c]

temporary dependency version overrides (in our normal «update/pin old where needed/investigate» upproach) would become a bit more annoying with this style in all-packages.nix…

[oxij]

Sure, but I did not invent this style, this is the style that is already used in all-packages.nix.

[7c6f434c]

… unfortunately. Although it seems that this abbreviation indeed doesn't lead to the expected problem in practice.

[oxij]

ping?

[7c6f434c]

Indeed.

[oxij]

Thanks!