CI Broken: Debian Bookworm and Fedora-37 can't install PySide2 via Pypi #330
Assignees
Milestone
Comments
|
@apyrgio I tried following your suggestion of building from debian's source from source (which is supposed to support python3.11). I needed to install There are some other quirks to get to to fail early, but in general, it is not easy to go this route. And my guess it that it won't be very stable. |
|
A way easier solution is to use install and use python3.10 on those systems. |
deeplow
added a commit
that referenced
this issue
Feb 1, 2023
In both Fedora 37 and Debian Bookworm, doing pip install fails. The reason for this is because they both have python 3.11 which our project doesn't support via poetry. By installing python 3.10 this allows us to do `poetry install` in a distro with python 3.11. Bumping the project's python version was not a viable solution since PySide2 version from Pypi does not support python 3.11. Fixes #330
|
After discussing with @apyrgio, we'll be using PySide6 exclusively in the development environment but when shipping to linux distros, we'll use PySide2. It will be tested anyways in QA before any release. This will ease these dependency issues. |
apyrgio
added a commit
that referenced
this issue
Feb 6, 2023
Drop PySide2 from our dependencies (previously used only on Linux environments) and use PySide6 in all dev environments. The reason is that PySide2 (from PyPI) does not support Python 3.11, and the variants that do (Fedora/Debian packages) need to backport fixes from PySide6. Our original attempt was to build PySide2 wheels for Python 3.11 but it was not simple, nor maintainable. So, we were left with two options: 1. Install Python 3.10 in dev environments that have Python 3.11 by default. 2. Use PySide6 in all of our environments. In both cases, we break package parity with the user's system, since we are not testing Dangerzone under the same conditions. However, since option (2) is forwards-compatible with where we want to move the project (use Qt6 and PySide6), we chose that one. Fixes #330
apyrgio
added a commit
that referenced
this issue
Feb 7, 2023
Drop PySide2 from our dependencies (previously used only on Linux environments) and use PySide6 in all dev environments. The reason is that PySide2 (from PyPI) does not support Python 3.11, and the variants that do (Fedora/Debian packages) need to backport fixes from PySide6. Our original attempt was to build PySide2 wheels for Python 3.11 but it was not simple, nor maintainable. So, we were left with two options: 1. Install Python 3.10 in dev environments that have Python 3.11 by default. 2. Use PySide6 in all of our environments. In both cases, we break package parity with the user's system, since we are not testing Dangerzone under the same conditions. However, since option (2) is forwards-compatible with where we want to move the project (use Qt6 and PySide6), we chose that one. Fixes #330
apyrgio
added a commit
that referenced
this issue
Feb 7, 2023
Drop PySide2 from our dependencies (previously used only on Linux environments) and use PySide6 in all dev environments. The reason is that PySide2 (from PyPI) does not support Python 3.11, and the variants that do (Fedora/Debian packages) need to backport fixes from PySide6. Our original attempt was to build PySide2 wheels for Python 3.11 but it was not simple, nor maintainable. So, we were left with two options: 1. Install Python 3.10 in dev environments that have Python 3.11 by default. 2. Use PySide6 in all of our environments. In both cases, we break package parity with the user's system, since we are not testing Dangerzone under the same conditions. However, since option (2) is forwards-compatible with where we want to move the project (use Qt6 and PySide6), we chose that one. Fixes #330
apyrgio
added a commit
that referenced
this issue
Feb 7, 2023
Drop PySide2 from our dependencies (previously used only on Linux environments) and use PySide6 in all dev environments. The reason is that PySide2 (from PyPI) does not support Python 3.11, and the variants that do (Fedora/Debian packages) need to backport fixes from PySide6. Our original attempt was to build PySide2 wheels for Python 3.11 but it was not simple, nor maintainable. So, we were left with two options: 1. Install Python 3.10 in dev environments that have Python 3.11 by default. 2. Use PySide6 in all of our environments. In both cases, we break package parity with the user's system, since we are not testing Dangerzone under the same conditions. However, since option (2) is forwards-compatible with where we want to move the project (use Qt6 and PySide6), we chose that one. Fixes #330
apyrgio
added a commit
that referenced
this issue
Feb 7, 2023
Drop PySide2 from our dependencies (previously used only on Linux environments) and use PySide6 in all dev environments. The reason is that PySide2 (from PyPI) does not support Python 3.11, and the variants that do (Fedora/Debian packages) need to backport fixes from PySide6. Our original attempt was to build PySide2 wheels for Python 3.11 but it was not simple, nor maintainable. So, we were left with two options: 1. Install Python 3.10 in dev environments that have Python 3.11 by default. 2. Use PySide6 in all of our environments. In both cases, we break package parity with the user's system, since we are not testing Dangerzone under the same conditions. However, since option (2) is forwards-compatible with where we want to move the project (use Qt6 and PySide6), we chose that one. Fixes #330
apyrgio
added a commit
that referenced
this issue
Feb 7, 2023
Drop PySide2 from our dependencies (previously used only on Linux environments) and use PySide6 in all dev environments. The reason is that PySide2 (from PyPI) does not support Python 3.11, and the variants that do (Fedora/Debian packages) need to backport fixes from PySide6. Our original attempt was to build PySide2 wheels for Python 3.11 but it was not simple, nor maintainable. So, we were left with two options: 1. Install Python 3.10 in dev environments that have Python 3.11 by default. 2. Use PySide6 in all of our environments. In both cases, we break package parity with the user's system, since we are not testing Dangerzone under the same conditions. However, since option (2) is forwards-compatible with where we want to move the project (use Qt6 and PySide6), we chose that one. Fixes #330
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In both Fedora 37 and Debian Bookworm, doing
pip installfails. The reason for this is because they both have python 3.11 which our project doesn't support via poetry.The text was updated successfully, but these errors were encountered: