I ended up running the "Fedora Loves Python" session at Flock. As the
It seems that the Fedora ❤ Python initiative has recently become
stagnated. It's not that Fedora no longer loves Python, but the
relationship has become rather boring, after several years
of marriage. I'd like to figure out, with people who understand
metrics and marketing more than we do, what to do next.
(or alternatively: We love the F♥P stickers, but the sticker budget
people want reasons to print more!)
This session was not recorded. (Ithers were, and the recordings might be
Here are some rough notes for anyone who'd like to run through them.
I'll most likely end up prioritizing and fleshing out some of the ideas
Please ask if something interesting has too little info :)
> Fedora Loves Python discussion at Flock Budapest 2019
> • Introduction round
> • Mirek Suchy’s suggestion
> • `setup.py bdist_rpm` produces ugly results. Even though we have pypa2rpm, most
people don’t know about it. Let’s improve this
> • Petr’s response: that part of setuptools can’t really be improved, it’s going
to be dismantled piece by piece into different projects
> • pyp2rpm is unmaintainable, it does too much guessing. We’re trying to move to
pyproject macros, which are standard based
> • Discussion about single-specfile vs. different specfiles for Fedora/EPEL/etc.
> • Petr recommends different specfiles, not merging branches, at most
> • Especially if it’s hard to coordinate between Fedora and EPEL, it’s better to
have different specfiles.
> • You want EPEL stable, so you generally won’t cherry-pick that many changes from
> • Questions to answer from the sticker budget person:
> “What would help me help here is an engineering understanding of (subject to
revision and extension): ”
> “a) why is working in Python a better experience than other platforms;”
> “b) what changes/configs/etc. does Fedora do that makes this better (in an
edition or spin or whatever);”
> • Fedora does better than other distros because it tries to NOT MODIFY the
upstream Python. Fedora tries to work upstream and do the reasolable changes there and not
downstream in Fedora. Other distros by and large don’t do this.
> • We should really market this more (and better). Offering the upstream
experience is a lot of work.
> “c) do we have docs on the definitive way to work with python to build an app for
deployment (I’m thinking about system packages vs pypi kind of stuff).”
> • Petr: Should we even have this?
> • Neal Gompa: Yes, for example if you have crypto in your module, a system
module is better
> • Neal: Also talk about Containers, very important
> • Petr: We need to figure out Fedora package names as dependencies upstream
> • Tomas Orsava: Having the documentation on how to build an app would help us
> • Petr: Yes, if we want the stickers we should have that docs. Who’s gonna
> • Mention also the Fedora Python Tox container
> • Neal Gompa shares why he likes Python on Fedora
> • In Fedora it’s way easier to test Python code than on other distros: It has
*working* PyPy, micropython, tox, Python 2, new Python 3 and also really old versions of
Python 3 - it’s really easy to test on everything at the same time
> • Fedora uses Python for its infrastructure
> • Meta discussion about the session: We need marketing people to help us promote
Fedora Loves Python, but this session has only engineers.
> • Lumir Balhar’s idea: We have Fedora Python Tox container, which as Tox pre-loaded
and ready to test all versions
> • https://github.com/frenzymadness/fedora-python-tox
> • To be moved to fedora-python project on github soon
> • Usable for various testing and also on a CI pipeline
> • Petr’s suggestions: Make it run with podman, make it into a GitHub app
> • Pavol Babincak’s idea: Have axillary modules packaged for every available Python
version in Fedora, e.g. rpm, dnf bindings that you can’t get from pypi
> • Neal Gompa says it would take too much maintenance, building gets super long,
you have to install so many Python versions and their developer packages, it would really
slow down development
> • Petr suggests to package these packages (even bindings) on PyPI. It is not
straight forward, but it’s doable, and we can try to even improve it.
> • Important: Libvirt for non-default Python
> • autotools is a problem in this regard, meson (autotools replacement) is
starting to be a problem
> • Neal Gompa: Jython is in danger because Java is exploding.
> • Petr: Does anybody actually use Jython? [crickets]
> • Lumir: Even Pytest doesn’t work with Jython
> • Petr: PyPI problem - anybody can upload wheels to it and there’s no way to check it
actually corresponds to the published sources
> • Petr: Do we want to build wheels?
> • Neal: - In RPM? No point, just harder to debug
> • Mirror PyPI? That’d be interesting! Fedora would be the only one crazy
to try it
> • Mirek Suchy: We already rebuilt PyPI in COPR, but having problems
with storage, ~50% packages rebuilt fine on Fedora without intervention
> • Petr: Raspberry PI foundation rebuilds all the PyPI wheels for
their funky ARM variant, it works
> • Neal: Copr would be better than mirroring PyPI, because we already
have the infrastructure
> • Mirek: Need funding!
> • Tomas: Would we be recommending copr install over pip install
> • Petr: Probably would need some kind of dnf pip install
> • Talking about dnf packages seeing pip-installed packages etc.
> • Virtualenvs vs Containers
> • Petr: If we want to start recommending Cotainers, we should be
installing stuff directly into the system
> • Licence issues: Are we worried about rebuilding packages in copr
from the licence point of view?
> • Petr: setup.py doesn’t even include licence by default
> • Neal: poetry and flit do!
> • Neal/Petr: PyPI should prompt people for a licence, warn if a
LICENCE file is missing
> -> Petr: if someone makes a PR, it’s probably gonna be
> • Neal: Repoclosure of Rawhide
> • Repoclosure checks that abstract dependencies are satisfiable
> • There’s no gating to check for this either