python-devel May 2022

python-devel@lists.fedoraproject.org

7 participants
6 discussions

planning to orphan python-django (and a couple of dependent packages)
by Matthias Runge 06 Jul '22

06 Jul '22

Hello there, you may or may not know, I have been maintaining python-django for quite some time in the past, some time as part of my job. My role changed and I really can not dedicate Django the time it deserves. I am looking for someone or persons willing to take - python-django - python-django-angular - python-django-appconf - python-django-authority - python-django-compressor - python-django-contact-form - python-django-debug-toolbar - python-django-haystack - python-django-mptt - python-django-nose - python-django-notification - python-django-pagination - python-django-pipeline - python-django-piston - python-django-pyscss - python-django-rest-framework - python-django-reversion - python-django-robots - python-django-tables2 - python-django-tagging Matthias

2 2

Python installation paths, pip, F36
by Owen Taylor 09 Jun '22

09 Jun '22

[ At Miro's request, resending this to python-devel so the discussion can be public ] Hi Miro - When rebuilding a package to include in a Flatpak, we want to install *everything* under prefix=/app - that includes Python modules. (Paths will be adjusted properly when running the Flatpak.) For years, the way we did that is by installing a /usr/lib64/python3.10/distutils/distutils.cfg: === [install] prefix=/app === This is part of the flatpak-rpm-macros package that gets installed in the buildroot for Flatpak rebuilds In Fedora 36, this no longer works for 'pip install' - it seems that pip unconditionally uses 'sysconfig' rather than 'distutils' to determine install paths for Python >= 3.10. I see that you filed https://github.com/pypa/pip/issues/10647 which landed in pip for pip-22, but Fedora 36 / pip-21 this isn't present? And in any case, that seems like it's something for 'sudo pip install' rather than package installation. I actually don't really follow how the Python macros are getting things installed into /usr/lib rather than /usr/local/lib. Any advice about how we can make the installation into /app work? Hopefully in a future-proof way... Thanks!!! Owen

3 11

Retiring Python 3.7 before Python 3.6?
by Miro Hrončok 30 May '22

30 May '22

Hey Pythonistas, let me include you in my dilemma I have wrt different Python versions we support in Fedora for testing. tl;dr Should we retire Python 3.7 before Python 3.6? 3.6 will stick around for RHEL 8, but 3.7 will no longer be "needed". However, retiring mid-order might be confusing. Note that this topic is not urgent at all, I am just curious about what is the best plan for the future. Python 3.7 retirement date ========================== Python 3.7 has security support upstream until June, 2023. It is also used in Debian 10 “Buster” -- LST ends June, 2024. Ubuntu seem to have skipped this Python version, so no LTS to consider there. Same with the SUSE Linux Enterprise Server. If nothing changes significantly, Fedora 40 will be released in April 2024, hence the natural thing to do would be to retire Python 3.7 in Fedora 40. (I might have made an error, evaluating the dates. Please, do correct me if there is a significant platform that supports Python 3.7 beyond Debian 10 LTS EOL or if some dates are wrong.) Python 3.6 retirement date ========================== Python 3.6 will be supported until RHEL 8 goes EOL. Which will likely not happen until 2029 [1]. That means, we might consider retiring it in Fedora 50 (wow). My dilemma ========== If we retire 3.7 before 3.6, the situation will be harder to explain to our users. Why is there a gap, they might ask. In the future, the list of supported Python versions might look weird and contain multiple gaps as we are eventually going to face this situation again with 3.8, 3.10... If we keep 3.7 around until 3.6 goes down, it will be harder to maintain. If it was just 3.7, that would probably be acceptable, but assuming no release schedules change, we will likely have Python 3.18 in Fedora 50. That means we would need to support 12 different Python 3.X versions by then if we haven't started introducing those gaps. Now we support 6. As I written this down, I think the better thing to do is to accept the gaps and retire Python 3.7 before Python 3.6 right away and not decide to "keep it around, as we still support both 3.6 and 3.8". WDYT? [1] https://access.redhat.com/support/policy/updates/errata -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

2 4

Re: [EPEL-devel] %generate_buildrequires
by Orion Poplawski 23 May '22

23 May '22

On 12/3/20 14:06, Andrew C Aitchison wrote: > On Thu, 3 Dec 2020, Michel Alexandre Salim wrote: > >>> Apart from the usual package-not-available story (which I want to fix >>> as part of my work bringing up the EPEL Packagers SIG), my current >>> snag is that python-tox-current-env uses %generate_buildrequires which >>> does not work on CentOS 8: >>> >>> CentOS 8 is still on RPM 4.14: >>> <mock-chroot> sh-4.4# rpm -q rpm >>> rpm-4.14.2-37.el8.x86_64 >>> >>> I'll put up a patch to hardcode dependencies for non-Fedora releases, >>> though that sorts of defeat the purpose of dynamic build >>> requirements. >>> Then again, this is only needed for EPEL8, since EPEL9 will have a >>> new enough RPM. >>> >> Given that %generate_buildrequires is the selling point of pyproject- >> rpm-macros, I'm guessing a better way forward for EPEL8 would be to not >> require it on EPEL8 since there's no way it would work, since RH won't >> update RPM? >> >> https://src.fedoraproject.org/rpms/pyproject-rpm-macros I've been playing around with a hacked version of pyproject-rpm-macros which at least allows some basic functionality in EPEL8. Comments welcome. https://src.fedoraproject.org/rpms/pyproject-rpm-macros/pull-request/284 -- 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/

1 0

pyproject-rpm-macros 1.2.0: Improved support for alternate build backends (e.g. hatchling)
by Miro Hrončok 06 May '22

06 May '22

Hello Pythonistas. I am glad to announce the release of pyproject-rpm-macros 1.2.0. The new version is available in rawhide and waits for your karma in updates-testing for older Fedoras: https://bodhi.fedoraproject.org/updates/FEDORA-2022-80586f3147 https://bodhi.fedoraproject.org/updates/FEDORA-2022-d4047b4440 https://bodhi.fedoraproject.org/updates/FEDORA-2022-64c16b2d38 Update for c9s will follow shortly. What's new since 1.0.0 ====================== Version 1.1.0 introduced support for nested directories in the *.dist-info metadata directory. This was not needed before, as there was no known build backend creating such directories. However, hatchling [1] does that and more and more packages in Fedora are using it. This is a backward-compatible change and you should not need to change anything unless you listed files in nested directories manually -- this workaround can now be removed. The removal is optional: if not removed RPM will only warn about files listed twice. More importantly, version 1.2.0 added support for reading runtime dependencies via %pyproject_buildrequires for build backends not supporting the PEP 517 prepare_metadata_for_build_wheel [2] (such as hatchling as well). Until now, when you wanted to get the runtime dependencies (%pyproject_buildrequires -r: the default) or use other functionality depending on it (%pyproject_buildrequires -x/-t/-e) and the backend did not support it, it failed -- you had to disable it by using -R. However, PEP 517 explicitly says: """ If a build frontend needs this information and the method is not defined, it should call build_wheel and look at the resulting metadata directly. """ %pyproject_buildrequires now provisionally support exactly that with the new -w flag. When -w is used, the wheel is built and the macro looks at the resulting metadata directly. Read all about it in the README [3] in the "Adding run-time and test-time dependencies" section. A short tl;dr here: - due to technical limitations, the wheel is built twice - you can omit %build/%pyproject_wheel to avoid building it for the 3rd time - don't patch/sed between %pyproject_buildrequires -w and %pyproject_wheel - the -w flag builds the wheel even when the hook exists As this is a provisional functionality, the API and/or behavior might change in the future. Hence it is not yet mentioned in the packaging guidelines. You are allowed to use it if you are prepared for potential breakage in the future. Where to get help ================= Report bugzillas [4] or write to this list [5] if you encounter any problems or if you need help. [1] https://pypi.org/project/hatchling/ [2] https://peps.python.org/pep-0517/#prepare-metadata-for-build-wheel [3] https://src.fedoraproject.org/rpms/pyproject-rpm-macros/blob/rawhide/f/READ… [4] https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=pyprojec… [5] Fedora Python SIG <python-devel(a)lists.fedoraproject.org> Happy packaging, -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

3 3

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

python-devel May 2022