Hello!
I ended up running the "Fedora Loves Python" session at Flock. As the
abstract says:
> It seems that the Fedora ❤ Python initiative has recently become more
> 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
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
_______________________________________________
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
