-
-
Notifications
You must be signed in to change notification settings - Fork 14.2k
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
pythonPackages.toPythonModule: also support overridePythonAttrs
.
#95687
base: master
Are you sure you want to change the base?
Conversation
The `overridePythonAttrs` method is for overriding `buildPython*` builders. Packages that use `toPythonModule` directly are typically bindings build not using `buildPython*`. This commit allows also those packages to be overridden with `overridePythonAttrs`, insteading actually invoking `overrideAttrs`. The motivation for this is to offer a common user interface for users of the Python packages set. This way they only need to know about `overridePythonAttrs` when overriding the builder, and `override` when overriding the `callPackage` call. Related RFC NixOS/rfcs#67.
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.
Sounds good/reasonable to me.
- Diff LGTM
- Commits LGTM
- Build: no build attempted
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.
diff LGTM
}); | ||
}) // { | ||
overridePythonAttrs = drv.overrideAttrs; | ||
}; |
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.
Problems:
- This is not composable: You can't
overridePythonAttrs
twice overrideAttrs
doesn't support non-functions, so.overridePythonAttrs {}
fails, leading to inconsistent behavior with theoverridePythonAttrs
thatmakeOverridablePythonPackage
defines.
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 see. Any suggestion how this can be resolved by adding the override option after the original function (stdenv.mkDerivation
) has already been called? This here also seems a case where NixOS/rfcs#3 would be helpful.
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.
Usually this is done by calling the original function again, but I think this get really messy with multiple ways to override things. Maybe look at the implementation of makeOverridable
I marked this as stale due to inactivity. → More info |
The
overridePythonAttrs
method is for overridingbuildPython*
builders. Packages that use
toPythonModule
directly are typicallybindings build not using
buildPython*
.This commit allows also those packages to be overridden with
overridePythonAttrs
, insteading actually invokingoverrideAttrs
.The motivation for this is to offer a common user interface for users of
the Python packages set. This way they only need to know about
overridePythonAttrs
when overriding the builder, andoverride
whenoverriding the
callPackage
call.Related RFC NixOS/rfcs#67.
Motivation for this change
Things done
sandbox
innix.conf
on non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
./result/bin/
)nix path-info -S
before and after)