We have a policy that patches for the same issue in the python and
python3 packages should share the same number. This informally extends
to EL and other derived distros, so the number of spec files to keep in
sync grows big.
To manage the patch numbers, Tomáš Orsava and a bunch of others have
been maintaining a list of relevant patches on the wiki:
I'd like to make that more official by moving it to
[[SIGs/Python/PythonPatches]] and mentioning it in the spec files.
Let me know if you think it's not a good use of the SIG's namespace.
At EuroPython and Flock this year, it became obvious that one thing Red
Hat's Python maintenance team is doing quite badly is communicating and
collaborating on this list. We're doing lots of stuff in Fedora, but we
should really do it as python-sig, rather than as individual contributors.
Please accept my apologies for this situation. We'll try to do better
from now on, and move Fedora-related talk to here and #fedora-python on IRC.
To get everyone here up to speed, here are some projects and plans, from
things that are mostly done to wild ideas. If you want more info, please
ask! (And, preferably, start a new thread...)
## Python 3 Migration
We're getting really close to having 50% Python packages in Fedora
ported to Python 3. The effort is tracked at
http://fedora.portingdb.xyz/, which also has a guide for contributing.
Bugs are tracked at https://bugzilla.redhat.com/show_bug.cgi?id=1285816
which links to mass filing information.
## Python 3 Porting Guides
A guide for updating RPM specs is live at
There's a work-in-progress guide for porting Python code, focused on the
tough nuts and uncooperative upstreams (because others have ported by
now, right?). Released early here: http://portingguide.readthedocs.io
## Python Packaging Guidelines
The Guidelines could be clearer; hopefully we can:
- fix the mistakes and confusing parts
- modernize them (without sacrificing quality)
- improve the process of contributing to them
## Automation of Packaging
Ideally, packagers should focus on vetting packages, integrating with
the system, and licence/legal compliance. Spec files tend to have lots
of boilerplate and, sometimes, arcane magic that distracts from those
tasks. Hopefully, that can be automated.
The pyp2rpm tool can convert PyPI packages to RPM specs (with varying
success rates, but Michal is working on that). COPR can automatically
rebuild packages as they're uploaded to PyPI.
Improving both these tools *and* Python's general packaging story should
let packagers focus on the tasks suited for humans.
## Packaging Python itself
Python 3.6 is coming out too late for Fedora 25, but we'll get it into
into Rawhide/26, as soon as possible.
For juggling patches across various Python version in various
Fedora-related distros, Tomáš created this page:
https://fedoraproject.org/wiki/User:Torsava/PythonPatches. It should
really be in a more official location.
Over the years, patches that are obsolete or upstreamable (e.g. stuck on
review) have piled up. Cleanup efforts should focus on python3 in Rawhide.
System Python is way to get Python with a stripped-down stdlib for
minimal cloud images. It's in Fedora already; the corresponding Change
page has more details. We're talking to DNF to adopt it.
## Breaking up the Standard Library
While most Python devs consider the standard library indivisible, pretty
much all distros break out tests and/or tkinter. Outside Linux,
py2exe/py2app/pyinstaller work with subsets of the standard library. And
as Python moves to the mobile workd with its self-contained apps,
there'll be more and more pressure for a standard way to leave out
pieces of the stdlib. We should write the PEP for that.
## Making "sudo pip install" Play Nice
"sudo pip install" should not break system-installed packages. Telling
people not to use "sudo pip" is, unfortunately, not really a solution.
We should look at what Debian does, and standardize in appropriate
channels (probably PyPA).
## Reviving Python-SIG
The wiki page at https://fedoraproject.org/wiki/SIGs/Python is somewhat
outdated, and it presents a rather confusing mix of information for
Experience with portingdb has shown me that a bit of work with HTML and
CSS can go a long way toward getting people interested, so let's do that
for the SIG as well.
We can use the fedoralovespython.org domain.
## My other projects
These don't really fall either under Fedora's python-SIG (or Red Hat
python-maint shared goals, for that matter). But I'll list them here for
- I'm working to port Samba to Python 3.
- I'm working on isolating CPython subinterpreters; low-level details