-
-
Notifications
You must be signed in to change notification settings - Fork 15.3k
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
Conversation
699feab
to
68d0fed
Compare
@@ -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); |
There was a problem hiding this comment.
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.
Interesting change. Does this impact memory usage? |
@GrahamcOfBorg eval it should have posted the performance report ... |
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:
|
Yeah looking much better now (only 3.5% slower), not sure how much I can trust the eval time now. |
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
68d0fed
to
a4896cb
Compare
@Profpatsch Yeah good point, did that, now best reviewable by commit |
@jonringer Got any concerns about this change? |
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 |
@jonringer (asking because you put a 😕 on the PR) |
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 :) |
Hehe, this time in the performance report:
|
There was a problem hiding this 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.
override = overrideArgs; | ||
overrideDerivation = fdrv: overrideResult (x: overrideDerivation x fdrv); | ||
${if result ? overrideAttrs then "overrideAttrs" else null} = fdrv: | ||
overrideResult (x: x.overrideAttrs fdrv); |
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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
@Profpatsch Can you take another look? |
There was a problem hiding this 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.
999a5ab
to
a4896cb
Compare
@GrahamcOfBorg eval Not sure why it failed evaluation, seems unrelated |
lib.makeOverridable: Propagate function arguments (cherry picked from commit 1230fc8)
Motivation for this change
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
f args
is a function, propagates its arguments tomakeOverridable f args
This allows querying function arguments even after it's been
makeOverridable'd. E.g.
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