python-devel December 2024

python-devel@lists.fedoraproject.org

11 participants
11 discussions

Heads-up: deprecating python-pytest-runner
by Michel Lind 24 Dec '24

24 Dec '24

Dear all, pytest-runner has been considered deprecated upstream since 2019: https://github.com/pytest-dev/pytest-runner/commit/78a492cb9f611a4fccaf6556… and the repo upstream was archived over a year ago (December 3, 2023). As such, and given the test suite never worked (it ran 0 tests, see https://kojipkgs.fedoraproject.org//packages/python-pytest-runner/4.0/24.fc…) prior to `setup.py test` being removed in setuptools 74 (https://bugzilla.redhat.com/show_bug.cgi?id=2319709) and that the only test defined requires Internet access anyway - I've now disabled tests and added import checks instead, and marked the package as `deprecated()` - so this should not be used for new packages. The upstream deprecation notice provided a guidance for switching away from `pytest-runner` - you should always be able to just invoke `%pytest` directly anyway Affected packages (maintainers bcc-ed) bst-external : python3dist(pytest-runner) cozy : python3dist(pytest-runner) pyp2rpm : python3dist(pytest-runner) python-accuweather : python3dist(pytest-runner) python-aioasuswrt : python3dist(pytest-runner) python-aiohttp-sse-client : python3dist(pytest-runner) python-arpeggio : python3dist(pytest-runner) python-astral : python3dist(pytest-runner) python-cid : python3dist(pytest-runner) python-cs : python3dist(pytest-runner) python-datrie : python3dist(pytest-runner) python-decopatch : python3dist(pytest-runner) python-devolo-home-control-api : python3dist(pytest-runner) python-django-prometheus : python3dist(pytest-runner) python-flask-caching : python3dist(pytest-runner) python-flask-gravatar : python3dist(pytest-runner) >= 2.6.2 python-gios : python3dist(pytest-runner) python-healpy : python3dist(pytest-runner) python-inject : python3dist(pytest-runner) python-makefun : python3dist(pytest-runner) python-multiaddr : python3dist(pytest-runner) python-multibase : python3dist(pytest-runner) python-multicodec : python3dist(pytest-runner) python-multihash : python3dist(pytest-runner) python-ncclient : python3dist(pytest-runner) python-nixio : python3dist(pytest-runner) python-pytest-cases : python3dist(pytest-runner) python-pytest-harvest : python3dist(pytest-runner) python-pytest-steps : python3dist(pytest-runner) python-reflink : python3dist(pytest-runner) python-slackclient : python3dist(pytest-runner) python-ssdeep : python3dist(pytest-runner) python-token-bucket : python3dist(pytest-runner) python-waterfurnace : python3dist(pytest-runner) python-xdfile : python3dist(pytest-runner) spec2scl : python3dist(pytest-runner) vyper : python3dist(pytest-runner) Best regards, -- _o) Michel Lind _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 README: https://fedoraproject.org/wiki/User:Salimma#README

1 1

Re: Heads-up: deprecating python-pytest-runner
by Michel Lind 24 Dec '24

24 Dec '24

On Tue, Dec 24, 2024 at 09:15:29AM -0500, Ben Beasley wrote: > I agree with the plan, but I wanted to note that deprecating a package that > other packages depend on requires a FESCo-approved Change[1]. > > (It is weird that the deprecation policy is so much more bureaucratic than > the retirement policy. By comparison, I don’t know of any policy that would > forbid summarily retiring a package that others depend on. It’s a bad > practice, and one might be asked to allow someone else to unretire and > maintain the package if the consequences are bad enough, but I’ve never seen > a blanket policy against it.) > > [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-packa… > You're right on both counts - I'll file a Change Proposal later today, and if it did not get accepted I can unmark the package as deprecated later. > I opened PR’s (or in some cases committed directly) to remove the > pytest-runner dependency from the following packages for which I am a direct > or group/SIG co-maintainer, sending PR’s upstream where applicable. > Thank you! Best regards, -- _o) Michel Lind _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 README: https://fedoraproject.org/wiki/User:Salimma#README

1 0

Need help with pywt
by Orion Poplawski 20 Dec '24

20 Dec '24

I'm trying to update pywt to 1.6 or 1.8 here: https://src.fedoraproject.org/rpms/python-pywt/pull-request/6 I'm running into an issue where it seems that I must install the built wheel locally so that I can then build the docs, but I don't know how to do that. When I do that locally it works (network!) but then I get doc build failures as well. TIA, Orion -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion(a)nwra.com Boulder, CO 80301 https://www.nwra.com/

2 2

Any Python HTML (generation) library packaged in Fedora?
by arequipeno＠gmail.com 11 Dec '24

11 Dec '24

I am looking for a Python library in Fedora that can be used for generating HTML. Google shows that a number of them exist, but I haven't yet found one that is actually packaged for Fedora (and I'd really prefer not to sully my soul with pip). Am I missing anything? Thanks!

1 0

Re: Fontmake needed for generating variable font from source
by Ben Beasley 11 Dec '24

11 Dec '24

With cooperation from Athos Ribiero, Parag Nemade, and Benson Muite, I’ve completed all of the necessary dependency work and posted fontmake for review at https://bugzilla.redhat.com/show_bug.cgi?id=2331684. Thanks! I’m targeting Rawhide only for now, since I’m reluctant to upgrade python-glyphsLib from 5.x to 6.x in stable releases, but that should be a compatible upgrade in practice, so it’s probably feasible to bring fontmake to F41 and F40 if someone really needs it. I also opened a PR for cascadia-code-fonts, https://src.fedoraproject.org/rpms/cascadia-code-fonts/pull-request/3. Unfortunately, I wasn’t able to go as far as actually building the font from sources with fontmake, but the PR does at least take a few steps in that direction. On 12/8/24 8:53 AM, Athos Ribeiro wrote: > On Sun, Dec 08, 2024 at 07:30:08AM -0500, Ben Beasley wrote: >> I had the idea of packaging fontmake on my back burner long ago, >> although I had abandoned the project. I just pulled together a draft >> spec file, https://music.fedorapeople.org/fontmake.spec. The current >> version of fontmake looks reasonably straightforward to package, with >> the following caveats: >> >> - no pathops extra; this would require a python-skia-pathops >> package, which is nontrivial due to the involvement of Skia >> >> - no autohint extra for now; this would require a >> python-ttfautohint-py package, which is probably feasible >> >> - no repacker extra for now; this would require a >> python-uharfbuzz package, and then enabling the repacker extra in the >> fonttools package, which is probably feasible >> >> The json extra can be packaged, at least in Rawhide, now that >> https://src.fedoraproject.org/rpms/python-ufoLib2/pull-request/3 is >> merged – thanks! >> >> Finally, python-glyphsLib needs to be updated to version 6.x first. >> It’s pretty far behind right now. I opened a PR, >> https://src.fedoraproject.org/rpms/python-glyphsLib/pull-request/1, >> to get to version 5.3.2 and generally bring it into the modern era, >> then another, >> https://src.fedoraproject.org/rpms/python-glyphsLib/pull-request/2, >> to update to the latest version. That will require a new dependency, >> openstep-plist, which I submitted for review in >> https://bugzilla.redhat.com/show_bug.cgi?id=2330988. >> >> Once all of that happens, I can submit fontmake for review. >> >> – Ben Beasley (FAS: music) >> > > Thanks, Ben! > > +1 > > I added you as an admin in python-glyphsLib. >

1 0

Retire Python 3.8 from Fedora 42+?
by Miro Hrončok 10 Dec '24

10 Dec '24

Hey Pythonistas, - Python 3.8 reached upstream End of Life 2024-10-07. - RHEL 8 Python 3.8 Stream has been retired since May 2023. - Debian buster had Python 3.7, bullseye has 3.9. - Ubuntu 20.04 LTS (Focal Fossa) has Python 3.8. - Standard support ends April 2025. Fedora 42 release date is April 2025. Hence I think we should retire Python 3.8 from Fedora 42+ Any other use case for Python 3.8 I missed? -- Miro Hrončok -- Phone: +420777974800 Fedora Matrix: mhroncok

2 3

Fontmake needed for generating variable font from source
by Anirban Mitra 08 Dec '24

08 Dec '24

Fontmake is a python tool required to generate variable fonts from designspace and ufo sources. I have created a variable font which I want to package for fedora. But I couldn't find fontmake in fedora packages. So do I need to package fontmake first to be able to package my font or I can install it through pip during the build stage of my package and list only python3 and pip as dependency.

3 2

3 python packages for Multipart Handler
by Sérgio Basto 07 Dec '24

07 Dec '24

Hi, I just notice that we have in Fedora 3 python packages for Multipart Handler [1] I'm maintainer of python-MultipartPostHandler2 and I think the package can be orphan and retired later , because now we have one replacement . The other two I don't know if they do the same or not. Best regards, [1] https://src.fedoraproject.org/rpms/python-python-multipart https://src.fedoraproject.org/rpms/python-multipart https://src.fedoraproject.org/rpms/python-MultipartPostHandler2 -- Sérgio M. B.

2 1

Let's drop /usr/local/lib(64)/python3.X/site-packages once and for all
by Miro Hrončok 06 Dec '24

06 Dec '24

Hello Pythonistas. tl;dr I wonder if we should get rid of the last downstream-only patch in Fedora's Python, the one responsible for /usr/local/lib(64)/python... installation location. The removal would bring us closer to upstream, but perhaps cause a regression for our users. I propose to adapt PEP 668 (Marking Python base environments as “externally managed”) instead. Details: On Python 3.13+ we only ship one downstream-only patch in Python. That is a patch that is not yet upstreamable, isn't a backport etc. The patch is this: https://src.fedoraproject.org/rpms/python3.13/blob/f39/f/00251-change-user-… (Deliberately linking f39 to make the link stable. Rawhide is currently the same.) Or as a commit: https://github.com/fedora-python/cpython/commit/ac3a9df5f8 We carry this patch in various forms for 7+ years. It originated with https://fedoraproject.org/wiki/Changes/Making_sudo_pip_safe The idea is this: - sudo pip install etc. installs to /usr/local/lib(64)/python3.X/site-packages - RPM packages are installed in /usr/lib(64)/python3.X/site-packages - RPM installed software ignores the packages in /usr/local (unless they opt in not to) - other software uses packages from both, giving preference to /usr/local There are several challenges to this approach: One of them is upgrading. Ideally if pyfoo 1 is installed via RPM, sudo pip install --upgrade 'pyfoo>=2' should install pyfoo to /usr/local while leaving the RPM-installed pyfoo 1 be. In reality, pip is not ready for this and needs a patch as well: https://src.fedoraproject.org/rpms/python-pip/blob/f39/f/remove-existing-di… This means that users who do sudo pip install --upgrade pip lose this patch. This also means that the fact that this appears to work in other Python package managers (such as uv) is probably purely accidental. This behavior also tends to differ for RPM-packaged Python packages with .dist-info and .egg-info metadata. Another challenge is the mechanism we decided to use for RPM packages to ignore /usr/local. We use the -s flag in shebangs for this. That leads to problems like this: "global pip installed modules not visible if user site dir is disabled" https://bugzilla.redhat.com/2256190 We could probably solve this by introducing a custom flag instead of -s, but that would make the patch even worse -- our RPM-packaged software would not even execute without our Python with our patch. I don't want to do that. A result of this problem (which is shared with Debian-based distros) was PEP 668 – Marking Python base environments as “externally managed” https://peps.python.org/pep-0668/ Except we cannot use it as is, because our install locations share a common stdlib location. I described this at https://discuss.python.org/t/pep-668-marking-python-base-environments-as-ex… and further. At this point, after 2 years of failure, I really don't know how to get something from this that's upstreamable. I spoke about this at PyCon PL '22 as well: https://www.youtube.com/watch?v=7SBH4PkbMhw --- Recently it occurred to me that perhaps we could: 1. drop the patches from Python and pip 2. mark /usr/lib(64)/python3.X as externally managed (PEP 668) And declare sudo-pip-installing unsupported. (That means, it only works with a custom pip flag and if users nuke their systems by using that flag, they shot themelves and we cannot help them.) Personally, I think this would be the best solution: sudo-pip-installing is bad and should never be done (no, not even in containers). However, I realize that others might disagree. For them, I can offer pip --break-system-packages. If we want to do this, I think we need to do this on Python upgrade boundary. We don't want users sudo pip-installing packages with Python 3.13 on Fedora 41 only to find them ignored on Fedora 42. However, when we upgrade Python to 3.14 in Fedora 43, their packages would still be broken anyway. -- Miro Hrončok -- Phone: +420777974800 Fedora Matrix: mhroncok

5 7

Deprecating %pyproject_buildrequires -w
by Miro Hrončok 05 Dec '24

05 Dec '24

Hey Pythonistas, now when we have %pyproject_buildrequires -p, I paln to deprecate -w. https://src.fedoraproject.org/rpms/pyproject-rpm-macros/pull-request/502 The flag was provisional and no Fedora package needs it any more. The -w and -p flags are both useful for build backends that don't implement the optional prepare-metadata-for-build-wheel hook. -p reads the metadata from a standardized TOML file -w builds the wheel and reads the metadata from it Both of them unfortunately need to do this repeatedly. -p is very fast, -w is slow (very slow for complex packages) Technically, not all backends support -p. But the overlap of known backends that don't and those that don't have the prepare-metadata-for-build-wheel hook is currently empty. -- Miro Hrončok -- Phone: +420777974800 Fedora Matrix: mhroncok

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

python-devel December 2024