Re: New version for a python package doesn't support python3.6 -- How to build for LEAP 15.4
Hi, I am cross-posting to python@lists.opensuse.org, because I think the discussion as progressed into a topic more suitable for that list. I suggest replying to that list only. On 07.12.22 15:37, t.gruner@katodev.de wrote:
A first step could be a repository like 15.4_py310 in d:l:p and there subprojects. I thing the most packages works well already. A few packages have hard coded python3 dependencies, but these one could split in mulitbuild or change to the actual/primary python. This will be find out when these repositories are available.
The whole python maintainers did a great job already and to use a second python version beside the default one is a short leap.
Yes coinstallable python versions work great in Tumbleweed, but unfortunately the adoption to Leap is not a walk in the park. Until recently (Matej mentioned the plans for 15.5) SUSE denied multi-flavors for SLE/Leap. Thus, many specfiles assume: %if 0%{?suse_version} < 1550 # I only have python3 (and python2 in <=15.3) and it is 3.6 and that won't change %endif This assumption needs to be rectified in more than a few specfiles. Another aspect: Just making 15.4_py310 in d:l:p without connections to its subprojects would fail at the first package in the dependency chain outside of d:l:p, e.g. pytest. d:l:p:backports solves this by linking almost all python packages from Factory into one project. However, have a look at the already existing 15.4_py39 there, it is not in a good state: https://build.opensuse.org/project/monitor/devel:languages:python:backports?arch_x86_64=1&defaults=0&repo_15_4_py39=1 Whoever set it up, I think they would welcome contributions to make it better. It may even be bumped to 15.4_py310 or a future 15.5_py310 for development of the announced coinstallability in 15.5 eventually. - Ben
On Sat, Dec 10, 2022 at 9:24 PM Ben Greiner
Hi,
I am cross-posting to python@lists.opensuse.org, because I think the discussion as progressed into a topic more suitable for that list. I suggest replying to that list only.
On 07.12.22 15:37, t.gruner@katodev.de wrote:
A first step could be a repository like 15.4_py310 in d:l:p and there subprojects. I thing the most packages works well already. A few packages have hard coded python3 dependencies, but these one could split in mulitbuild or change to the actual/primary python. This will be find out when these repositories are available.
The whole python maintainers did a great job already and to use a second python version beside the default one is a short leap.
Yes coinstallable python versions work great in Tumbleweed, but unfortunately the adoption to Leap is not a walk in the park. Until recently (Matej mentioned the plans for 15.5) SUSE denied multi-flavors for SLE/Leap. Thus, many specfiles assume:
%if 0%{?suse_version} < 1550 # I only have python3 (and python2 in <=15.3) and it is 3.6 and that won't change %endif
This assumption needs to be rectified in more than a few specfiles.
Another aspect: Just making 15.4_py310 in d:l:p without connections to its subprojects would fail at the first package in the dependency chain outside of d:l:p, e.g. pytest.
d:l:p:backports solves this by linking almost all python packages from Factory into one project. However, have a look at the already existing 15.4_py39 there, it is not in a good state:
Whoever set it up, I think they would welcome contributions to make it better. It may even be bumped to 15.4_py310 or a future 15.5_py310 for development of the announced coinstallability in 15.5 eventually.
- Ben
I have submitted my updated python-dfdatetime package to factory. As I stated originally, it requires python 3.7 or newer. Once it is in factory, I will check devel:languages:python:backports and see if there is a python 3.9 build for LEAP 15.4 automatically available. If so and testing shows it works, I will inform my known users of LEAP 15.4 python-dfdatetime that they need to add devel:languages:python:backports to their repo list to run python-dfdatetime. If testing shows it is failing, I will try to submit SRs that resolve the issues in devel:languages:python:backports that are preventing this latest release of python-dfdatetime from being usable in Leap 15.4. Thanks, Greg
Am 14.12.22 um 23:27 schrieb Greg Freemyer:
On 07.12.22 15:37,t.gruner@katodev.de wrote:
A first step could be a repository like 15.4_py310 in d:l:p and there subprojects. I thing the most packages works well already. A few packages have hard coded python3 dependencies, but these one could split in mulitbuild or change to the actual/primary python. This will be find out when these repositories are available.
The whole python maintainers did a great job already and to use a second python version beside the default one is a short leap.
Yes coinstallable python versions work great in Tumbleweed, but unfortunately the adoption to Leap is not a walk in the park. Until recently (Matej mentioned the plans for 15.5) SUSE denied multi-flavors for SLE/Leap. Thus, many specfiles assume:
%if 0%{?suse_version} < 1550 # I only have python3 (and python2 in <=15.3) and it is 3.6 and that won't change %endif
This assumption needs to be rectified in more than a few specfiles.
Another aspect: Just making 15.4_py310 in d:l:p without connections to its subprojects would fail at the first package in the dependency chain outside of d:l:p, e.g. pytest.
d:l:p:backports solves this by linking almost all python packages from Factory into one project. However, have a look at the already existing 15.4_py39 there, it is not in a good state:
Whoever set it up, I think they would welcome contributions to make it better. It may even be bumped to 15.4_py310 or a future 15.5_py310 for development of the announced coinstallability in 15.5 eventually.
- Ben I have submitted my updated python-dfdatetime package to factory. As I stated originally, it requires python 3.7 or newer.
Once it is in factory, I will check devel:languages:python:backports and see if there is a python 3.9 build for LEAP 15.4 automatically available.
If so and testing shows it works, I will inform my known users of LEAP 15.4 python-dfdatetime that they need to add devel:languages:python:backports to their repo list to run python-dfdatetime.
Note that in previous discussions, there were people mentioning that d:l:p:backports is not for end-user consumption. Those mentions didn't take the _py39 repository into account though. We'll see how the efforts Dirk mentioned will change things.
If testing shows it is failing, I will try to submit SRs that resolve the issues in devel:languages:python:backports that are preventing this latest release of python-dfdatetime from being usable in Leap 15.4.
Before your submissions you can always check locally with osc build --alternative-project=devel:languages:python:backports x86_64 15.4_py3 Or add this to your home project meta (see e.g. https://build.opensuse.org/projects/home:bnavigator:branches:devel:languages...): <repository name="15.4_py39"> <path project="devel:languages:python:backports" repository="15.4_py39"/> <arch>x86_64</arch> </repository>
Thanks, Greg
HTH Ben
I have submitted my updated python-dfdatetime package to factory. As I stated originally, it requires python 3.7 or newer.
Once it is in factory, I will check devel:languages:python:backports and see if there is a python 3.9 build for LEAP 15.4 automatically available.
If so and testing shows it works, I will inform my known users of LEAP 15.4 python-dfdatetime that they need to add devel:languages:python:backports to their repo list to run python-dfdatetime.
Note that in previous discussions, there were people mentioning that d:l:p:backports is not for end-user consumption. Those mentions didn't take the _py39 repository into account though. We'll see how the efforts Dirk mentioned will change things.
If testing shows it is failing, I will try to submit SRs that resolve the issues in devel:languages:python:backports that are preventing this latest release of python-dfdatetime from being usable in Leap 15.4.
Before your submissions you can always check locally with
osc build --alternative-project=devel:languages:python:backports x86_64 15.4_py3
Or add this to your home project meta (see e.g. https://build.opensuse.org/projects/home:bnavigator:branches:devel:languages...):
<repository name="15.4_py39"> <path project="devel:languages:python:backports" repository="15.4_py39"/> <arch>x86_64</arch> </repository>
I added the above to security:forensics and it is now building python39 packages for the ~50 python modules in there. I just installed python39-dfdatetime from the security:forensics 15.4_py39 repo. Unfortunately, it doesn't have all the dependencies it needs:
./run_tests.py Using Python version 3.9.15 (main, Oct 28 2022, 17:28:38) [GCC] Checking availability and versions of dependencies.
Checking availability and versions of test dependencies. [FAILURE] missing: mock [FAILURE] missing: pbr [FAILURE] missing: six I'll see if I can figure out SRs to start addressing those. Thanks, Greg
Am16.12.22 um 05:04 schrieb Greg Freemyer:
Before your submissions you can always check locally with
osc build --alternative-project=devel:languages:python:backports x86_64 15.4_py3
Or add this to your home project meta (see e.g. https://build.opensuse.org/projects/home:bnavigator:branches:devel:languages...):
<repository name="15.4_py39"> <path project="devel:languages:python:backports" repository="15.4_py39"/> <arch>x86_64</arch> </repository> I added the above to security:forensics and it is now building python39 packages for the ~50 python modules in there.
My suggestion was for development and local test not for end-user consumption. You will need to branch the whole dependency tree into securoty:forensics. Using the whole d:l:p:backports as zypper repo is strongly discouraged.
I just installed python39-dfdatetime from the security:forensics 15.4_py39 repo.
Unfortunately, it doesn't have all the dependencies it needs:
./run_tests.py Using Python version 3.9.15 (main, Oct 28 2022, 17:28:38) [GCC] Checking availability and versions of dependencies.
Checking availability and versions of test dependencies. [FAILURE] missing: mock [FAILURE] missing: pbr [FAILURE] missing: six
I'll see if I can figure out SRs to start addressing those.
Those are not runtime dependencies they are only listed in test_requirements.txt and not even really needed for those anymore. Upstream just did not clean up their code: https://github.com/log2timeline/dfdatetime/blob/20221112/test_requirements.t... https://github.com/log2timeline/dfdatetime/search?q=mock https://github.com/log2timeline/dfdatetime/search?q=pbr https://github.com/log2timeline/dfdatetime/search?q=six
Thanks, Greg
- Ben
participants (2)
-
Ben Greiner -
Greg Freemyer