python-devel August 2026

python-devel@lists.fedoraproject.org

7 participants
6 discussions

is this the right place to ask a fedora packaging question related to python
by Carl Byington 01 Sep '26

01 Sep '26

If so, I have a package that is waiting for review, bugzilla 2497737. The upstream code base has three folders (core, hscommon, qt) referenced via statements like: from core import __version__, __appname__ It seems that would potentially conflict with other applications, so adding a dupeguru namespace changes that to from dupeguru.core import __version__, __appname__ That seems to require a reorganization of the source tree, moving those three folders down one level so we have dupeguru/core, etc.Is that the proper approach, or is there some simpler way?

2 2

%pyproject_patch_dependency behavior wrt. multiple packages in one spec
by Miro Hrončok 28 Aug '26

28 Aug '26

Hello, So I've used %pyproject_patch_dependency in a specfile that packages two Python distribution packages. It filtered the dependencies from both. Is this expected? Should it gain some finer tuning (--dist-name argument perhaps)? -- Miro Hrončok -- Phone: +420777974800

2 3

Plan for flit-core v4
by Maxwell G 24 Aug '26

24 Aug '26

Hi everyone, A new major version of flit and flit-core was recently released [1]. Flit documentation previously recommended that packages pin flit-core to `<4` in pyproject.toml metadata, which many projects did. There are 152 packages in rawhide that BuildRequire 'python3dist(flit-core)'. About 80% of those pin '<4'. Note that, according to the flit changelog, > This version contains breaking changes, but most projects which are already using the [project] table for metadata shouldn’t be affected, and can simply change the flit_core <4 constraint to <5. so for many packages, the required changes would just be changing one character ("4" to "5") in pyproject.toml (or patching the dependencies using the %pyproject_patch_dependency macro as described below), but for other packages that use `[tool.flit.metadata]`, the required changes would be more involved. How should we handle this? A couple potential options: 1. Mass add `%pyproject_patch_dependency flit-core:drop_upper` to all affected packages where possible. This is the most quick-n-dirty solution, but it doesn't contribute anything back to upstream projects. This solution also wouldn't work for packages that need to be ported away from `[tool.flit.metadata]`. We would need to figure out how many tool.flit.metadata users there still are and handle them separately. 2. Start an effort to patch package dependency constraints in pyproject.toml to allow both v3 and v4 and port [tool.flit.metadata] usage where applicable. Send the patches to upstreams. Then, upgrade python-flit-core to v4. 3. Update python-flit-core to v4 first, add a deprecated() v3 compat package, and then slowly on patching flit-core users and eventually removing the compat package. Any thoughts about these ideas or other things that I missed? It would be nice to get this figured out before F46 branching so we don't get stuck with an old flit in EL 11. All the best, Maxwell [1] https://bugzilla.redhat.com/show_bug.cgi?id=2511191

2 2

Drop second copy of LICENSE file?
by Tadej Janež 22 Aug '26

22 Aug '26

Hey, I've noticed that python3-pypdf includes the LICENSE 2 times: $ rpm -q --licensefiles python3-pypdf /usr/lib/python3.14/site-packages/pypdf-6.16.1.dist- info/licenses/LICENSE /usr/share/licenses/python3-pypdf/LICENSE This is due to including it both via %pyproject_save_files macro and manually via the '%license LICENSE' line: https://src.fedoraproject.org/rpms/python-pypdf/blob/5244ee1de1ad01cb3759e7… Originally, it needed to be manually added because it was not pulled in automatically by the build backend: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproj… Is it correct to drop the '%license LICENSE' now and ensure a LICENSE file is present via '%pyproject_save_files --assert-license'? See https://src.fedoraproject.org/rpms/python-pypdf/pull-request/4 Thanks and regards, Tadej

2 2

%pyproject_patch_dependency macro now available (provisional)
by Charalampos Stratakis 14 Aug '26

14 Aug '26

Hello folks, Tired of figuring out the right sed or patch to modify dependency constraints in your Python packages? Or having your carefully crafted regex break because upstream reformatted their metadata? %pyproject_patch_dependency is here to help. A new macro has been merged into pyproject-rpm-macros and is available in Rawhide, F44 and F43 as a provisional feature. It provides a uniform way to override upstream dependency constraints in %prep, regardless of the build backend. It affects both BuildRequires and runtime Requires. Example usage: %prep %autosetup -p1 %pyproject_patch_dependency cython:drop_upper %pyproject_patch_dependency numpy:set_upper:3.0 %pyproject_patch_dependency legacy-dep:ignore It also handles circular/sibling dependencies in multi-wheel specs via the br_only suffix. A sibling package can be ignored in BuildRequires (since it's not yet installed during build) while keeping it as a runtime Requires: %pyproject_patch_dependency sibling-package:ignore:br_only The feature is marked provisional, meaning the API may change based on real-world usage. If you maintain Python packages and deal with dependency version overrides, I'd appreciate if you gave this a try and reported any issues. Documentation (Provisional: Overriding dependency constraints section) <https://src.fedoraproject.org/rpms/pyproject-rpm-macros/blob/rawhide/f/READ…> <https://src.fedoraproject.org/rpms/pyproject-rpm-macros/blob/rawhide/f/READ…> Implementation <https://src.fedoraproject.org/rpms/pyproject-rpm-macros/c/5d9798f289ea8cbeb…> F44 bodhi update <https://bodhi.fedoraproject.org/updates/FEDORA-2026-c50219cb79> F43 bodhi update <https://bodhi.fedoraproject.org/updates/FEDORA-2026-051d1b3285> -- Regards, Charalampos Stratakis Senior Software Engineer Python Maintenance Team, Red Hat

4 6

RFC: Generate python(abi) Requires for any files in pythonX.Y directory
by Miro Hrončok 12 Aug '26

12 Aug '26

Hello Pythonistas. tl;dr The python(abi) Requires are currently only generated for .py or .so files. I think that restriction is not useful and would like to drop it. I opened https://src.fedoraproject.org/rpms/python-rpm-generators/pull-request/80 in response to https://src.fedoraproject.org/rpms/python-coverage_pth/blob/0401cae6/f/pyth… It extends the generated python(abi) Requires for any (all?) files in pythonX.Y directory regardless of their extension or type. It does not matter if the package installs .py, .so or different files. Packages that simply drop a .pth file to site-packages or even only carry dist-info folder still need to Require the package that owns /usr/lib(64)/pythonX.Y. Since the PR was opened couple months ago and received no feedback, I decided to share it here as well. WDYT? -- Miro Hrončok -- Phone: +420777974800

3 5

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

python-devel August 2026