python-devel March 2022

python-devel@lists.fedoraproject.org

9 participants
10 discussions

Splitting alternative Python packages into subpackages, e.g. python3.11{,libs,devel,...}
by Tomáš Orsava 05 May '22

05 May '22

Hi Python-devel, we are considering splitting the alternative Python versions from a single-package format (e.g. python3.11) to multiple subpackages (e.g. python3.11{,-libs,-devel,-tkinter,-test,-idle}). We do this already with the main `python3` package: it requires less disk space to install and speeds up download times, because you can chose which bits are important to you. For example, if you decide you don't need python3-tkinter, you save yourself ~18 dependent packages leading to a total savings of ~20MBs, while skipping python3-test saves you further ~10MBs. What do you think? The push came from [BZ#2063227] where the reporters would welcome to have a smaller python3.11 package for containers and VMs for local testing, CI purposes and more. This would be a larger amount of work, so our initial reaction was hesitant. We'll have to change the already complicated spec file %bcond logic, and adjust the ecosystem to work with the new subpackages. For example tox would need to Recommend `python3.11-devel`, as `python3.11` would bring in only the bare interpreter. And of course a thorough integration testing would be in order. However, we already do separate subpackages for alternative stacks in Enterprise Linux (CentOS /Stream, RHEL, EPEL) and as a general rule we consider it good to have fewer differences between Fedora and EL. This helps to test things earlier, and there are fewer surprises in user experience. So perhaps the effort in doing this would be well spent. To cut down on the amount of work, we're considering changing only the `python3.11` package (and any future newer versions) right now. If later we consider it worth it, we could switch the older alternative interpreters as well, or we might let them die out as they are. We're currently in the brainstorming stage, so you're feedback is welcome. [BZ#2063227] https://bugzilla.redhat.com/show_bug.cgi?id=2063227 All the best, Tomáš

4 5

Re: Retire unused nose plugins?
by Miro Hrončok 24 Mar '22

24 Mar '22

On 21. 04. 20 15:58, Matthias Runge wrote: > On 21/04/2020 12:55, Miro Hrončok wrote: >> Hello. >> >> Given https://fedoraproject.org/wiki/Changes/DeprecateNose would you be >> OK if I retire python-nose_fixes, python-nose-xcover and >> python-nose-testconfig in rawhide? >> >> Nothing in Fedora depends on them: >> >> $ repoquery --repo=rawhide{,-source} --whatrequires python3-nose_fixes >> $ repoquery --repo=rawhide{,-source} --whatrequires python3-nose-xcover >> $ repoquery --repo=rawhide{,-source} --whatrequires python3-nose-testconfig >> >> Thanks, > yes, sure! There seem to be 2 more that can be dropped: $ repoquery --repo=rawhide{,-source} --whatrequires python3-nose_fixes $ repoquery --repo=rawhide{,-source} --whatrequires python3-nose-cover3 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

1 0

why opencv Python package doesn't provide python3dist(opencv-python) ?
by Sérgio Basto 15 Mar '22

15 Mar '22

Hi, Can someone help me ? https://src.fedoraproject.org/rpms/opencv/blob/rawhide/f/opencv.spec have py_provides but https://bugzilla.redhat.com/show_bug.cgi?id=2054951 Thank you . -- Sérgio M. B.

2 1

Dropping 32bit arches from pypy2.7?
by Miro Hrončok 11 Mar '22

11 Mar '22

Hello. pypy 2.7 fails to build with GCC 12 on 32 bit arches. https://bugzilla.redhat.com/show_bug.cgi?id=2046857 Instead of investigating this and trying to fix this, I wonder if I can just excludearch %ix86 and %arm32. No other Fedora package really requires pypy, (asv uses it in %check but it already excludes some arches). I am not aware of any multilib i686 use cases and we retired arm32 anyway. I would probably do this in Fedora 37 only, but if we need to rebuild the package in the future e.g. for a CVE fix or upgrade, excluding the arches on F36 would also help me. Any thoughts? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

2 4

Pytest 7 coming to rawhide next week
by Miro Hrončok 10 Mar '22

10 Mar '22

Hello Pythonistas, I intent to upgrade pytest in Rawhide to 7.0.x next week. There are ~18 packages affected at build time and 2 almost-unused pytest plugins are affected on runtime. See https://bugzilla.redhat.com/showdependencytree.cgi?id=PYTEST7 If you wish to test your changes against pytest 7, send a rawhide pull request to your package and it will show up in https://copr.fedorainfracloud.org/coprs/churchyard/pytest-7/builds/ -- alternatively, use that Copr repo directly, e.g. in mock or in another Copr. If you need help getting your package fixed with pytest 7, feel free to ask. If the problem remains unfixed, your package will fail to build from source starting next week. In the worst case scenario, I can help you package python-pytest6, but I do not wish to maintain that long term. Thanks, -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

1 1

[HEADS-UP] - python-setuptools 60.9.x is heading to Rawhide
by Karolina Surma 09 Mar '22

09 Mar '22

Hello, python-setuptools 60.9.x will be shipped to Rawhide on Friday, Mar 11. During the efforts to integrate the new version to Fedora we have discovered ~25 affected packages. Wherever it was straightforward to fix, I sent a Pull Request directly to the package repository in Fedora's dist-git. For more complex cases, a Bugzilla ticket was created. setuptools 60+ brings a significant behavior change: it makes its local copy of distutils the default. To override the new default, set the environment variable SETUPTOOLS_USE_DISTUTILS=stdlib. The setuptools' copy sometimes behaves differently than distutils from Python's standard library. If overriding, bear in mind that Python's distutils is deprecated and slated for removal in Python 3.12. We encourage you to work with the upstreams to fix the encountered distutils' issues, but ideally migrating away from distutils entirely. python-setuptools's license string has changed as some new libraries are vendored by the package. The new license is: 'MIT and ASL 2.0 and (BSD or ASL 2.0) and Python' (was: 'MIT and (BSD or ASL 2.0)'). Happy packaging, Karolina Surma

1 0

Is missing python3-docs in EL9 a problem?
by Orion Poplawski 05 Mar '22

05 Mar '22

I've been poking at some packages that BR python3-docs, like python-zope-event. This apparently comes from a sphinx inventory: # Use local objects.inv for intersphinx sed -i "s|$'https://docs\.python\.org/': $None|\1'%{_docdir}/python3-docs/html/objects.inv'|" docs/conf.py If I build without python3-docs present I get the following message but the build succeeds: Running Sphinx v3.4.3 making output directory... done loading intersphinx inventory from /usr/share/doc/python3-docs/html/objects.inv... WARNING: failed to reach any of the inventories with the following issues: intersphinx inventory '/usr/share/doc/python3-docs/html/objects.inv' not fetchable due to <class 'FileNotFoundError'>: [Errno 2] No such file or directory: '/usr/share/doc/python3-docs/html/objects.inv' Is this a problem or can we safely ignore it? Is there a better way to remove the intersphinx dep? If not, how best to get python3-docs into EL9? Thanks. -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion(a)nwra.com Boulder, CO 80301 https://www.nwra.com/

3 3

Making PyPy 3.9 the "main" pypy3 for Fedora 36?
by Miro Hrončok 03 Mar '22

03 Mar '22

Hello Pythonistas. Do you think we should make /usr/bin/pypy3 PyPy 3.9 in Fedora 36? It is rather late in the release cycle, but considering this is essentially a leaf package I think this might be a good idea. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

3 4

Orphaned python-aiohttp-cors
by Miro Hrončok 02 Mar '22

02 Mar '22

Hello, I've maintained python-aiohttp-cors because python-black required it, but it no longer does, so I've just orphaned it. The package is now only required by gns3-server. The package builds, installs, builds with Python 3.11 (we have just pushed a fix). However, it appears dead upstream. Consider dropping the dependency instead of taking the package. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

1 0

Looking for some review swaps
by Ben Beasley 01 Mar '22

01 Mar '22

I’d like to find some reviewers to clear out my backlog of mostly-Python packages. These vary from near-trivial to moderately complicated. I’m happy to review packages in exchange. I’m particularly comfortable with C, C++, and Python, but reviewing other kinds of packages is a possibility. It might be a few days before I have a chance to reciprocate. Thanks! – Ben Pure Python: python-opentype-sanitizer: https://bugzilla.redhat.com/show_bug.cgi?id=2049273 (for renaming python-ots to satisfy the PyPI parity policy) python-autoprop: https://bugzilla.redhat.com/show_bug.cgi?id=2038330 python-signature-dispatch: https://bugzilla.redhat.com/show_bug.cgi?id=2038330 python-autoclasstoc: https://bugzilla.redhat.com/show_bug.cgi?id=2038159 Python with Cython: python-asyncmy: https://bugzilla.redhat.com/show_bug.cgi?id=2041221 python-ezdxf: https://bugzilla.redhat.com/show_bug.cgi?id=2040816 C++: c4log: https://bugzilla.redhat.com/show_bug.cgi?id=2040461 (for packaging rapidyaml) casc: https://bugzilla.redhat.com/show_bug.cgi?id=2027121

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

python-devel March 2022