python-devel August 2019

python-devel@lists.fedoraproject.org

5 participants
5 discussions

[HEADS UP] Retiring python2 and introducing python27 later this week
by Miro Hrončok 10 Sep '19

10 Sep '19

We are retiring python2 and introducing python27 later this week. Rawhide only. As for now, nothing should break, except python2-debug will exist no more. Packages (build)requiring python2 or python2-devel should continue to work for now. If not, let us know. If you plan to keep a Python 2 package in Fedora 32+, talk to me, I can help you draft an exception request. Will post a reply here once it is done. The following packages build subpackages for python2-debug (and should stop doing it in Fedora 32+): - gcc-python-plugin (FTBFS) - python-mysql (PR exists) - python-psycopg2 (notified in an existing bugzilla) -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

4 11

New Contributor slee
by Scott Lee 27 Aug '19

27 Aug '19

Hello, I'm slee on FAS and interested in contributing to the Python SIG. I've read over the wiki and some of the Python 2to3 guides as well as looked over https://github.com/fedora-python. Please let me know if there's something in particular I can start helping with as well as if there's some guidance for new members -- I'm new to contributing to the Fedora ecosystem in general! I'm based on the West Coast so in PST timezone. My background is in operations engineering (Python, Bash, Ansible, Terraform, AWS, Kubernetes) but I'd love to learn more about Python packaging and help out in any way I can. Please let me know if I can add any other information. Thanks, and looking forward to hearing from the group!

1 0

[HEADS UP] Fedora 32 Python 3.8 rebuilds have started in a side tag
by Miro Hrončok 21 Aug '19

21 Aug '19

Hello, in order to deliver Python 3.8, we are running a coordinated rebuild in a side tag. https://fedoraproject.org/wiki/Changes/Python3.8 If you see a "Rebuild for Python 3.8" commit in your package, please don't rebuild it in regular rawhide. If you need to, please let me know, so we can coordinate. If you'd like to update the package, you should be able to build it in the side tag via: on branch master: $ fedpkg build --target=f32-python Note that it will take a while before the essential packages are rebuilt, so don't except all your dependencies to be available right away. Thanks. Let us know if you have any questions. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

1 1

Notes from the "Fedora Loves Python" session at Flock
by Petr Viktorin 14 Aug '19

14 Aug '19

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

1 0

Re: Removal of Python 2 from the Xfce spin
by Miro Hrončok 11 Aug '19

11 Aug '19

On 09. 01. 19 9:34, Miro Hrončok wrote: > Hi, we've successfully removed Python 2 from default Workstation installation > years ago, today I'd like to see if we could do it in Xfce Spin as well. Current rawhide Xfce spin is Python 2 free \o/ -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

python-devel August 2019