Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

all-packages.nix: move defaults to package files #55129

Merged
merged 38 commits into from Feb 13, 2019

Conversation

oxij
Copy link
Member

@oxij oxij commented Feb 3, 2019

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

These are already inherited in the parent derivation.
@@ -1,4 +1,4 @@
{stdenvNoCC, subversion, sshSupport ? false, openssh ? null, expect}:
{stdenvNoCC, subversion, sshSupport ? true, openssh ? null, expect}:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

, x11Support ? false, xlibsWrapper ? null
, cupsSupport ? false, cups ? null
, cupsSupport ? config.ghostscript.cups or (!stdenv.isDarwin), cups ? null
, x11Support ? cupsSupport, xlibsWrapper ? null # with CUPS, X11 only adds very little
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

licenseFile = config.gams.licenseFile or null;
optgamsFile = config.gams.optgamsFile or null;
};
gams = callPackage ../tools/misc/gams (config.gams or {});
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@oxij
Copy link
Member Author

oxij commented Feb 13, 2019

ping?

@7c6f434c 7c6f434c merged commit 8384cfe into NixOS:master Feb 13, 2019
@7c6f434c
Copy link
Member

Indeed.

@oxij
Copy link
Member Author

oxij commented Feb 13, 2019

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants