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

Python packageOverrides improvements #87388

Open
wants to merge 2 commits into
base: master
from

Conversation

@alyssais
Copy link
Member

@alyssais alyssais commented May 9, 2020

Between these two changes, complex uses of packageOverrides become a lot more tolerable (even if they’re still not pleasant). Explanations in commit messages.

alyssais added 2 commits May 9, 2020
This makes it so that if I apply a patch to Django using
packageOverrides, it's applied to python3.pkgs.python.pkgs.django
(and python3.pkgs.python.pkgs.python.pkgs.django) as well as
python3.pkgs.django.
This allows (manually) composing packageOverrides, like so:

    python3.override {
      packageOverrides =
        lib.composeExtensions python3.packageOverrides (final: super: { ... });
    }

This is still not great, but without this, you can't use
packageOverrides twice at all, because the second use just clobbers
the first with no way to make sure the first override is applied as
well.
@FRidh
Copy link
Member

@FRidh FRidh commented May 9, 2020

For python3.pkgs: apply packageOverrides recursively, this is why it is typically also needed to pass self = python; if I recall correctly.

Regarding python3: expose packageOverrides in passthru , see also #67422. Another idea was to offer the contents of python-packages.nix as a top-level "overlay" so what you want to do here could apply also to the other Python sets.

@alyssais
Copy link
Member Author

@alyssais alyssais commented May 9, 2020

@FRidh
Copy link
Member

@FRidh FRidh commented May 9, 2020

Does my change then remove the need to do that?

I don't think so. Consider you override both the interpreter build, and a package in the package set. In that case you really still need to pass self = python; to make it use that Python. Thus, your change should not be needed then.

pythonPackages = callPackage ../../../top-level/python-packages.nix {
python = self;
overrides = packageOverrides;
};

This is why I regret introducing the passthru to Python instead of just adding everything to pythonPackages like it's done for Haskell. It's ugly but way more practical.

Exposing packageOverrides is a nice simple change that makes multiple
overrides possible, if not pretty. It doesn't stop us doing it better
later, but I don't have the capacity to do that now.

I've said before this probably should go via an RFC but frankly I don't see that happening. This change is simple and very useful so IMO its good.

@FRidh
Copy link
Member

@FRidh FRidh commented Jul 2, 2020

Alternative at #91850.

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

Successfully merging this pull request may close these issues.

None yet

2 participants
You can’t perform that action at this time.