:::warning :atom_symbol: This process is a nuclear power plant. We don’t expect casual contributors to follow it. ::: :::info :construction: This is a WIP document. It'll be better in time. Ping @befeleme if you want to understand the unclear parts of it. There's also an older document which may contain interesting details not covered here: https://fedoraproject.org/wiki/SIGs/Python/UpgradingPython. ::: :::success

:::warning :atom_symbol: This process is a nuclear power plant. We don’t expect casual contributors to follow it. By we, we mean Red Hat's python-maint team, which currently handles Python interpreter maintenance in Fedora. If you're not in the team, you're certainly welcome to look how we do things and follow/improve this guide (or parts of it) if you want to, but your time might be better spent learning other things :) It's perfectly OK to just file bugs in Bugzilla, submit Pull Requests in Pagure, and talk on the mailing list. ::: :::info :construction: This document is work in progress. Python-maint members should have write access—if it doesn't work, ask @torsava. Feel free to edit to fix typos or reword sentences. Keep discussion in e-mail or in person, please avoid comments here, they are hard to follow. Feel free to add XXX notes.

Hello Pythonistas. tl;dr I wonder if we should get rid of the last downstream-only patch in Fedora's Python, the one responsible for /usr/local/lib(64)/python... installation location. The removal would bring us closer to upstream, but perhaps cause a regression for our users. I propose to adapt PEP 668 (Marking Python base environments as “externally managed”) instead. Details: On Python 3.13+ we only ship one downstream-only patch in Python.

Moved to https://discuss.python.org/t/pre-pep-standardizing-test-dependency-and-command-specification/71896

cffconvert cloud-init copr-backend copr-frontend copr-rpmbuild fedmsg git-up h5py httpie - PR ready ipython

Check what packages (transitively) BuildRequire your package $ repoquery --repo=rawhide{,-source} --whatrequires python3-foo --recursive | grep src$ | pkgname | sort | uniq > packages.txt Use --repo={fedora,updates}{,-source} --releasever XX --latest=1 instead of --repo=rawhide{,-source} for older releases. XXX: what does --latest=1 mean? Always use the package name for this, not a virtual provide. Note that the --recursive flag might give an enormous list of packages (e.g. for python3-setuptools), so feel free to not always use it. Check what packages might not even install the new version

obs-service-set_version https://copr.fedorainfracloud.org/coprs/thrnciar/python-packaging/package/obs-service-set_version/ test failures wrt some version manipulation for RPM? pcs https://copr.fedorainfracloud.org/coprs/thrnciar/python-packaging/package/pcs/ python3dist() provides generator:

Error: The version in the Python package metadata {version} normalizes to zero. It's likely a packaging error caused by missing version information (e.g. when using a version control system snapshot as a source). Try providing the version information manually when building the Python package, for example by setting the SETUPTOOLS_SCM_PRETEND_VERSION environment variable if the package uses setuptools_scm. If you are confident that the version of the Python package is intentionally zero, you may %define the _python_dist_allow_version_zero macro in the spec file to disable this check.

The contents of this document were moved to https://github.com/fedora-python/pull-request-review-guide

User Stories As a Fedora packager of a library I want to create a quality RPM package (conforming to the guidelines) in order to submit it to Fedora. As a devops person I want to quickly create a working RPM package of a Python library in order to install it on my machine(s). As a maintainer of a library

:warning: This is a ReST document. Most of it renders OK as Markdown, though. PEP: XXXX Title: pysource: File Layout for Installed Modules Author: Petr Viktorin pviktori@redhat.com, XXX add yourself :) Discussions-To: XXX Status: Draft Type: Standards Track Created: 04-Feb-2022

:::info 👉 https://hackmd.io/@python-maint/fedora-pr-process ::: What PR submitter does Ask for review: Paste the PR link to the team Etherpad Clearly mark the PR as WIP (ideally in the PR title)

In Fedora 36, Python changes the way installation paths of Python packages are handled. The changes affect the main Python in Fedora 36, Python 3.10, as well as any newer Python version included. Most Fedora users should not be affected by the change but there are situations where there might be slight differences. When Python packages are installed by sudo pip, sudo python setup.py install or similar methods, Python packages are installed to /usr/local/lib(64)/python3.10/site-packages/. This has already been happening since Fedora 27. However the way this is achieved has been significantly re-implemented in Fedora 36 and that has created several minor differences. The sysconfig Python module from the standard library defines several installation schemes. By default, the installation scheme used on Fedora 36 when installing Python packages using root privileges (for example via sudo) is {prefix}/local/lib(64)/python3.10/site-packages/ (where {prefix} is defined as /usr by default). When Python itself runs from a Python virtual environment or when building RPM packages, the installation scheme is {prefix}/lib(64)/python3.10/site-packages/ (it does not include /local/). Previously, the /local/ part was only artificially added when installing packages, now it is part of the installation scheme. This was changed to be more consistent with what other Python distributors are doing, so that the scheme is more likely to be accepted in upstream Python and to work well with upstream tools like setuptools or pip, which we cannot modify when they are installed or upgraded using pip directly from the Python Package Index. Here are the differences that might be observed with the new approach:

Moved to: https://github.com/encukou/slides/tree/master/2021-11-10-packagingcon

Links CPython code: https://github.com/python/cpython/blob/master/Lib/distutils/command/install.py Fedora patch: https://github.com/fedora-python/cpython/commit/acba1a24b6ad5b894b4d6ef3223c2d174e225d21 Debian patch: https://salsa.debian.org/cpython-team/python3-stdlib/blob/master/debian/patches/3.8/distutils-install-layout.diff PyPy patch: https://github.com/pypa/distutils/commit/2f1fae1bfceb88cf812a45c44cd18ce604b69c69#diff-6742915ffa9375e1830aa1e69016d3cf PR: https://github.com/pypa/distutils/pull/1 Initial discussion: https://discuss.python.org/t/how-can-we-keep-pip-from-updating-uninstalling-system-libraries-in-usr-lib-python/5059

# Sent

Intro Welcome to the Modern Python Packaging Hackfest! As you might know, the Python Packaging Guidelines were recently rewritten and there's a bunch of new macros around that can help you simplify Python packaging for Fedora. In this workshop, we can look at your spec file and introduce the new macros, or we can help you package something new in Fedora. Python packaging improvements

These are changes between the current (“201x-era”) Python packaging guidelines and the proposal as of 2021-03-03. All MUST and SHOULD items from both versions are covered. (For the old guidelines I added more, where I feel they should have been marked SHOULD.) If you have comments or reservations, please read the whole section of the new guidelines. Direct your comments to the Python SIG mailing list. (Comments on HackMD are hard to manage.) Minor changes are hidden in *details* tags like this. To open one, click the summary. (Now you can see these details.)