python-devel

python-devel@lists.fedoraproject.org

1000 discussions

pypy3.10 retirement plan
by Miro Hrončok 30 Sep '26

30 Sep '26

Hi, I plan to retire pypy3.10 from Fedora 46+ now when I packaged pypy3.12. Upstream no longer seem to be making releases of pypy3.10. Please, speak up if you see a reason to keep it. I will keep it in Fedora 45, considering how close we are to the final freeze. -- Miro Hrončok -- Phone: +420777974800

1 0

Self-introduction: Renato Loureiro
by Renato Loureiro 19 Sep '26

19 Sep '26

Salutations, python-devel. My name is Renato Loureiro, and I am a college student and software developer, mainly using the Python programming language. Alongside software devleopment, I also work on technical write-ups, as I also enjoy writing prose alongside code. I am currently residing in the United Kingdom. I've never contributed to the Fedora Project before, and the Python SIG would be the first group I would be joining. I've also been using Fedora Linux since 2023, and I wanted to contribute to the operating system that has made me able to work for so long. I think Python would be the best starting point to begin working on the Fedora Project, as I have to deal with it more often than not at college. At face value, I believe that the documentation on the wiki entry for the Python SIG should be enough to teach me how to package Python applications, and maintain them. If I'm struggling, I'll be sure to ask in the official channels. I'm excited to be working with everyone here! All the best, -- loureir-or-not Renato Loureiro

1 0

Collection of this group's data for a LLM-powered weekly report
by Aurelien Bompard 17 Sep '26

17 Sep '26

Hi folks, I'm generating a weekly report of activity in the Fedora project centered on teams and SIGs, it's called "This Week in Fedora" <https://abompard.fedorapeople.org/twif/>. This generation uses an LLM. The goal is to make it easier to catch up with everything that's going on in the project, and to give visibility to each group's work and requests for help or testing. I think that from a newcomer's point of view, having an insight on what a group is working on at a point in time is helpful to decide whether it's interesting and worth contributing to. I'm collecting activity from: - this mailing-list - discourse posts with the #python-sig tag In the latest version, I've added the possiblity to gather messages exchanged in Matrix channels. The #python channel is public and its entire history is available to new members, but a quite a few people in mutiple Matrix channels were unhappy about the LLM collecting this info, for various reasons. I would like to know whether this group is OK with my program collecting and submitting info to an LLM from the following sources: 1. mailing-lists and discourse posts 2. the matrix channel I would like to make the case for source 2 (the Matrix channel) because I think it's less obvious: knowing the "tone" of a conversation and the currently discussed subjects before joining is very important to help contribute to it. It's like when you're added to an empty group chat and you don't know how to start. That's why we show history to new channel members, and this would be the same idea at a higher level. Plus there's actual work going on in there for a lot of groups. That said, I recognize that the form of the tool influences its use, chat messages are usually less thought-through than emails or forum posts, and members could be indimidated that something they write there and regret end up in a visible summary (the program respects message edits, but anyway). Since my goal is to foster participation, the one thing I don't want to do is to hinder it in another way. I know I've asked this in the chat last week but someone in another room noted that people can easily miss Matrix messages, which it true. Please decide which collected sources, if any, you are OK with (and if you work in other places that you would like to have collected, of course (I can do RSS feeds!)). If the group is OK with Matrix channel collection but some individuals aren't, I can also exclude certain Matrix usernames from collection throughout the Matrix channels that are not meetings. I'm happy to answer questions if you have any. Thanks!

2 1

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

[heads-up] A targeted rebuild of Python packages with extension modules in Rawhide on Jul 22
by Karolina Surma 25 Jul '26

25 Jul '26

Hello, In the released Python 3.15.0b4 there was an incompatible ABI change[0] that forces us to one more rebuild of the packages with extension modules in a side tag. More precisely, we are rebuilding packages depending on python(abi) = 3.15 and libpython3.15.so.1.0()(64bit) that contain ".so" files or are installed into %python3_sitearch. There is about 750 packages in this targeted rebuild. We plan to do it tomorrow (July 22, 2026). Please, don't build your Python packages with extension modules in Rawhide until we confirm the side tag was merged. The rebuild will happen in f45-build-side-144323. Cheers, Karolina [0]: https://github.com/python/cpython/pull/152448

2 7

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

python-devel