Nixpkgs: Python packages depending on qt5, use qt514 while all-packages.nix defaults to qt515, causing incompatibilities.

Created on 7 Oct 2020  Â·  9Comments  Â·  Source: NixOS/nixpkgs

Describe the bug

Experienced here: https://github.com/NixOS/nixpkgs/pull/99465#issue-497263839 and here: https://github.com/NixOS/nixpkgs/pull/99685#issuecomment-704782836

How come pyqt5 winds up with qt-5.14 in it's inputs and in it's references? Considering:

https://github.com/NixOS/nixpkgs/blob/433db454f3f6925addb1d7e26f134ef67567ac02/pkgs/top-level/all-packages.nix#L15002-L15003

And:

https://github.com/NixOS/nixpkgs/blob/433db454f3f6925addb1d7e26f134ef67567ac02/pkgs/top-level/python-packages.nix#L5278-L5280

To Reproduce

nix-store --query --references $(nix-build --no-out-link -A python3.pkgs.pyqt5) | grep 5.14

Expected behavior

No qt5.14 references.

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.

Notify maintainers

cc @sander

Maintainer information:

# a list of nixpkgs attributes affected by the problem
attribute: python.pkgs.pyqt5
# a list of nixos modules affected by the problem
module:
bug python qkde

Most helpful comment

Applications can be overridden to use a different Qt, libraries cannot.

This is essentially correct, but let me expand on it:

  1. Restriction imposed by Qt: Any derivation that depends on Qt must have only one Qt version in its entire transitive closure.
  2. Applications can pick a particular version of Qt because nothing depends on them, so they can't violate restriction (1).
  3. As a consequence of (1) + (2), every library must be built with every version of Qt, so that applications have all their library dependencies available. Therefore, libraries don't get to pick a Qt version.

All 9 comments

Updating pyqt5 in https://github.com/NixOS/nixpkgs/pull/99933 does not solve the issue.

qt5 is overridden for all python. I described what I know of the history here: https://github.com/NixOS/nixpkgs/issues/99458#issuecomment-703910777.
I know of one reason to use qt514: qtwebkit is broken in qt515. But maybe @ttuegel can explain 282aadbd36c6f75cde7abf62562020f7d1c15341, 282aadbd36c6f75cde7abf62562020f7d1c15341 (why does pyqt5 need to have version 5.14)?

Anyway, I think packages shouldn't blindly expect any qt5 version in python. We should somehow add a test whether a package uses inconsistend qt5 versions, but in general, packages using pyqt5 should adapt to it or override it, since adapting is almost trivial. Unfortunately, overriding isn't: Look at qutebrowser here: #98197. Unfortunately, there is no check for inconsistent dependencies implemented, I think. Almost all python+qt5 packages that use inconsistent versions should fail.

Thanks for the references. To summarize, this explains the situation:

https://github.com/NixOS/nixpkgs/blob/626ce32e9fd52b8b73e499d29363e610be55c91e/pkgs/top-level/all-packages.nix#L10165-L10171

But why do that? This is not inline with all-packages.nix which defaults to 5.15. I suspect that more packages are affected and we don't know it yet. I also understand now how your picard PR fixes the issue.

I think we should remove that override, and override every python package to use libsForQt514 only if needed.

Applications can be overridden to use a different Qt, libraries cannot.

I don't know which one we should be using here. There was quite some confusion regarding the Qt versions, along with some incorrect commits (including mine) setting Qt versions for Python packages.

If we think the libraries should be built with 5.15, and overridden for certain applications, then that is of course fine, and we should remove this override.

Applications can be overridden to use a different Qt, libraries cannot. – @FRidh

Why? Because of Nixpkgs or because of the libraries themselves?
I think, in Nixpkgs you can override the qt version python libraries use, but only cleanly by overriding python.

If we think the libraries should be built with 5.15, and overridden for certain applications, then that is of course fine, and we should remove this override.

If we think the libraries are compatible with 5.15. At least qtwebkit isn't, but this is a qt library anyway and it's probably best overridden for every application using it.

Applications can be overridden to use a different Qt, libraries cannot.

This is essentially correct, but let me expand on it:

  1. Restriction imposed by Qt: Any derivation that depends on Qt must have only one Qt version in its entire transitive closure.
  2. Applications can pick a particular version of Qt because nothing depends on them, so they can't violate restriction (1).
  3. As a consequence of (1) + (2), every library must be built with every version of Qt, so that applications have all their library dependencies available. Therefore, libraries don't get to pick a Qt version.

Thank you for the explanation. That is exactly how it is for Python packages as well.

I think that is also what makes it so tricky here, both Qt and Python having these type of restrictions. For any package, all its Qt libraries need to be compatible, all its Python packages need to be compatible. Finally, the bindings that are used need to be handle the versions.

@ttuegel thanks for joining in. Could you please explain a bit more how did you pick the packages to use libsForQt514 in https://github.com/NixOS/nixpkgs/commit/22167ae45fb27fac1e6aec7d1bf6ce82516fcb12 ?

Could you please explain a bit more how did you pick the packages to use libsForQt514 in 22167ae ?

These packages didn't build with Qt 5.15, which we were about to make the default on master.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

domenkozar picture domenkozar  Â·  3Comments

retrry picture retrry  Â·  3Comments

teto picture teto  Â·  3Comments

ghost picture ghost  Â·  3Comments

rzetterberg picture rzetterberg  Â·  3Comments