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 
    • 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
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: 
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 

Reply via email to