Notes from the "Fedora Loves Python" session at Flock

Hello! I ended up running the "Fedora Loves Python" session at Flock. As the abstract says: (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 available later.) 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 later. 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 cherry-picking commits. > • 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 Fedora anyway. > > • 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 with newcomers > • Petr: Yes, if we want the stickers we should have that docs. Who’s gonna write it? > • 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 accepted! > > • Neal: Repoclosure of Rawhide > • Repoclosure checks that abstract dependencies are satisfiable > • There’s no gating to check for this either