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

lib.makeOverridable: Propagate function arguments #67809

Merged
merged 7 commits into from Oct 22, 2019

Conversation

infinisil
Copy link
Member

Motivation for this change
  • Propagate the arguments of f to (makeOverridable f args).override

This allows people to query what arguments they can override for
derivations without having to look at the nix expression with

nix-repl> lib.functionArgs pkgs.hello.override
{ fetchurl = false; stdenv = false; }
  • If f args is a function, propagates its arguments to
    makeOverridable f args

This allows querying function arguments even after it's been
makeOverridable'd. E.g.

nix-repl> lib.functionArgs pkgs.fetchgit
{ branchName = true; deepClone = true; fetchSubmodules = true; ... }

This is a continuation of #47535, this time with correct behavior even when .overrideDerivation or .overrideAttrs is used.

I took the liberty to remove the overrideDerivation = throw "overrideDerivation not yet supported for functors"; while I'm at it.

Ping @nbp @Profpatsch

Things done
  • Double-checked to make sure the code doesn't change any behavior

@@ -1,7 +1,7 @@
{ stdenv, lib, symlinkJoin, gimp, makeWrapper, gimpPlugins, gnome3, plugins ? null}:

let
allPlugins = lib.filter (pkg: builtins.isAttrs pkg && pkg.type == "derivation" && !pkg.meta.broken or false) (lib.attrValues gimpPlugins);
allPlugins = lib.filter (pkg: lib.isDerivation pkg && !pkg.meta.broken or false) (lib.attrValues gimpPlugins);
Copy link
Member Author

Choose a reason for hiding this comment

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

This change is necessary because gimpPlugins was makeOverride'd, meaning it has a .override, which previously was a function, but now is a functor attrset (but without a .type), which this function wasn't able to handle before. The lib.isDerivation function properly checks for that.

@FRidh
Copy link
Member

FRidh commented Aug 31, 2019

Interesting change. Does this impact memory usage?

@grahamc
Copy link
Member

grahamc commented Aug 31, 2019

@GrahamcOfBorg eval

it should have posted the performance report ...

@infinisil
Copy link
Member Author

infinisil commented Aug 31, 2019

Hm that doesn't look very good, why would eval time go up this much? I call bad luck, let's try again

@GrahamcOfBorg eval

This was the result for reference:

stat before after Δ Δ%
cpuTime 189.76 225.71 ↗ 35.95 18.94%
envs-bytes 3,013,206,344 3,022,604,696 ↗ 9,398,352 0.31%
envs-elements 162,003,077 162,976,653 ↗ 973,576 0.60%
envs-number 107,323,858 107,424,467 ↗ 100,609 0.09%
gc-heapSize 11,828,391,936 11,878,723,584 ↗ 50,331,648 0.43%
gc-totalBytes 23,316,522,048 23,352,482,976 ↗ 35,960,928 0.15%
list-bytes 1,591,287,664 1,591,287,664 0
list-concats 7,288,187 7,288,187 0
list-elements 198,910,958 198,910,958 0
nrAvoided 151,146,250 151,485,068 ↗ 338,818 0.22%
nrFunctionCalls 93,631,170 93,731,779 ↗ 100,609 0.11%
nrLookups 75,657,344 75,682,341 ↗ 24,997 0.03%
nrOpUpdateValuesCopied 230,487,746 230,496,380 ↗ 8,634 0.00%
nrOpUpdates 12,981,495 12,984,373 ↗ 2,878 0.02%
nrPrimOpCalls 66,132,513 66,132,513 0
nrThunks 155,344,587 155,998,851 ↗ 654,264 0.42%
sets-bytes 7,771,229,080 7,772,720,896 ↗ 1,491,816 0.02%
sets-elements 314,516,021 314,568,889 ↗ 52,868 0.02%
sets-number 27,855,572 27,883,445 ↗ 27,873 0.10%
sizes-Attr 24 24 0
sizes-Bindings 8 8 0
sizes-Env 16 16 0
sizes-Value 24 24 0
symbols-bytes 15,190,949 15,190,922 ↘ 27 -0.00%
symbols-number 334,133 334,134 ↗ 1 0.00%
values-bytes 5,461,096,464 5,477,392,272 ↗ 16,295,808 0.30%
values-number 227,545,686 228,224,678 ↗ 678,992 0.30%

@infinisil
Copy link
Member Author

Yeah looking much better now (only 3.5% slower), not sure how much I can trust the eval time now.

@Profpatsch
Copy link
Member

Can you split this PR into two/three/n commits, the implementation changes first and then any renaming/refactoring afterwards?

This is just a block of stuff and it’s very hard to see what is renaming, what is actual changes to the logic and what is reformatting/reflowing of the code.

And call it overrideArgs in the let binding because that's what it does
This allows querying the arguments you can .override:

  nix-repl> lib.functionArgs pkgs.hello.override
  { fetchurl = false; stdenv = false; }
…ction

This allows querying function arguments of things like fetchFromGitHub:

  nix-repl> lib.functionArgs pkgs.fetchFromGitHub
  { fetchSubmodules = true; githubBase = true; ... }
…tions

- Apparently nobody ever needed this
- We already have enough ways to override things
- Using overrideDerivation is discouraged
- Rename ff to result because that's what it is
- Better indentation
- Less parens
- Comment what overrideWith does
@infinisil
Copy link
Member Author

@Profpatsch Yeah good point, did that, now best reviewable by commit

@infinisil
Copy link
Member Author

@jonringer Got any concerns about this change?

@jonringer
Copy link
Contributor

No concerns code-wise. The inner-workings of nix looks like voodoo to me :)

For commit hygience, maybe squash a few of the minor ones together. Otherwise LGTM

@infinisil
Copy link
Member Author

@jonringer (asking because you put a 😕 on the PR)

@jonringer
Copy link
Contributor

oh, I think i meant to comment about how I couldnt make heads or tails of what magic you were doing. Sorry for the confusion :)

@infinisil
Copy link
Member Author

Hehe, this time in the performance report:

stat before after Δ Δ%
cpuTime 192.73 192.73 ↗ 0.00 0.00%

Copy link
Member

@Profpatsch Profpatsch left a comment

Choose a reason for hiding this comment

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

I found a few things.

lib/customisation.nix Show resolved Hide resolved
override = overrideArgs;
overrideDerivation = fdrv: overrideResult (x: overrideDerivation x fdrv);
${if result ? overrideAttrs then "overrideAttrs" else null} = fdrv:
overrideResult (x: x.overrideAttrs fdrv);
Copy link
Member

Choose a reason for hiding this comment

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

I’d like to see a deprecation of overrideDerivation, by throwing a warning and removing it next release (or the one after).

Copy link
Member Author

Choose a reason for hiding this comment

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

The attribute has been throwing an error already forever, so removing it is already the next step

lib/customisation.nix Show resolved Hide resolved
@infinisil
Copy link
Member Author

@Profpatsch Can you take another look?

Copy link
Member

@Profpatsch Profpatsch left a comment

Choose a reason for hiding this comment

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

Sorry for the wait, was on vacation for a week.

lib/trivial.nix Outdated Show resolved Hide resolved
@infinisil
Copy link
Member Author

@GrahamcOfBorg eval

Not sure why it failed evaluation, seems unrelated

@infinisil infinisil merged commit 1230fc8 into NixOS:master Oct 22, 2019
@infinisil infinisil deleted the propagate-override-args branch October 22, 2019 12:37
dtzWill pushed a commit to dtzWill/nixpkgs that referenced this pull request Oct 22, 2019
lib.makeOverridable: Propagate function arguments

(cherry picked from commit 1230fc8)
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

5 participants