python-devel August 2021

python-devel@lists.fedoraproject.org

10 participants
13 discussions

package request: PyWaffle
by Matthew Miller 20 Dec '21

20 Dec '21

Hi! I'm using this https://github.com/gyli/PyWaffle for some visualizations for Fedora Project stats. I'm kind of out of the loop on the state of the art of python packaging, and wondered if some kind Python SIG person would like to take it on for me.

4 12

Building docs of compiled extensions with new macros
by Elliott Sales de Andrade 15 Oct '21

15 Oct '21

I've been experimenting with the new macros for Python packages, and ran into some issues building Sphinx docs for compiled extensions. When building docs, one usually has to be able to import the project. When the project uses compiled extensions, it is not sufficient to point to the original unpacked sources, but instead must point to the built ones. However, since the new %pyprojec_wheel creates a wheel, I don't know how to do this properly. Setting e.g., PYTHONPATH=/path/to/*.whl doesn't seem to work (it seems to load everything else but the shared library): + pushd docs ~/build/BUILD/pikepdf-2.16.1/docs ~/build/BUILD/pikepdf-2.16.1 ++ ls /builddir/build/BUILD/pikepdf-2.16.1/docs/../pyproject-wheeldir/pikepdf-2.16.1-cp310-cp310-linux_x86_64.whl + PYTHONPATH=/builddir/build/BUILD/pikepdf-2.16.1/docs/../pyproject-wheeldir/pikepdf-2.16.1-cp310-cp310-linux_x86_64.whl + sphinx-build-3 . ../html Running Sphinx v4.1.2 Configuration error: There is a programmable error in your configuration file: Traceback (most recent call last): File "/builddir/build/BUILD/pikepdf-2.16.1/pyproject-wheeldir/pikepdf-2.16.1-cp310-cp310-linux_x86_64.whl/pikepdf/__init__.py", line 13, in <module> from . import _qpdf ImportError: cannot import name '_qpdf' from partially initialized module 'pikepdf' (most likely due to a circular import) (/builddir/build/BUILD/pikepdf-2.16.1/pyproject-wheeldir/pikepdf-2.16.1-cp310-cp310-linux_x86_64.whl/pikepdf/__init__.py) The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/usr/lib/python3.10/site-packages/sphinx/config.py", line 327, in eval_config_file exec(code, namespace) File "/builddir/build/BUILD/pikepdf-2.16.1/docs/conf.py", line 59, in <module> import pikepdf # isort:skip pylint: disable=unused-import File "/builddir/build/BUILD/pikepdf-2.16.1/pyproject-wheeldir/pikepdf-2.16.1-cp310-cp310-linux_x86_64.whl/pikepdf/__init__.py", line 16, in <module> raise ImportError(_msg) from _e ImportError: pikepdf's extension library failed to import -- Elliott

3 5

Migrating python-graphql-server to new guidelines
by Mattia Verga 30 Aug '21

30 Aug '21

Hello folks, I'm trying to migrate graphql-server spec file to the newer Python guidelines, but I'm hitting some walls. - Building the package locally went fine, while on Koji [¹] I get: error: line 39: Unknown tag: %pyproject_extras_subpkg -n python3-graphql-server flask webob aiohttp - The example spec file in the guidelines says to use the %tox macro, but I cannot test it locally, because I get: tox: error: unrecognized arguments: --current-env - graphql-server has a [flask] extra, but in beta4 it requires Flask<1, while in Fedora we have Flask>1... should I remove the extra by obsoleting it? How to properly do so for an extra, considering that all previous Provides were generated automatically? Thanks in advance for the help. Mattia [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=74321415

3 4

Obsoleting extras subpackages
by Elliott Sales de Andrade 30 Aug '21

30 Aug '21

In Dask, they have some extras that have effectively been removed, but they kept them in their config for backwards compatibility. In Fedora, I would like to remove the meta-subpackages, as they don't provide any additional Requires. As such, I would like to Obsolete them from the main package, and as a direct replacement, it should also Provides the old extra subpackage. Is there a way to automatically create all the various Provides aliases that %pyproject_extras_subpkg would normally do? -- Elliott

2 1

Re: Intent to retire python-typer and python-typer-cli
by Ben Beasley 30 Aug '21

30 Aug '21

Thanks for pointing this out. I’ll unretire typer and typer-cli, then, and give it another chance. It’s been less than eight weeks (only a few days!) so unretirement will be quick and will not require re-review. A little communication from the upstream maintainer would have really helped! - Ben On 8/30/21 6:22 AM, Chandan Kumar wrote: > Hello Ben, > > On Sat, Aug 21, 2021 at 12:36 AM Ben Beasley <ben(a)musicinmybrain.net> wrote: >> >> Unless someone convinces me of another plan, I intend to retire >> python-typer and python-typer-cli in F35 and Rawhide in one week >> (2021-08-27). >> >> I myself introduced these two packages to Fedora quite recently >> (https://bugzilla.redhat.com/show_bug.cgi?id=1964742, >> https://bugzilla.redhat.com/show_bug.cgi?id=1974118). No other packages >> currently depend on them. >> >> Upstream was in a period of inactivity that was not too worrisome at the >> time, but has become much more concerning as they have not responded at >> all to issues or PR’s on this project and have not made the necessary >> (nontrivial) changes to work with the new major release (8.x) of >> python-click. Please see https://github.com/tiangolo/typer/issues/313 >> for an overview of the situation and links to additional relevant issues. >> >> It might be possible to sustain these two packages in Fedora 35 by >> introducing a click 7.x compatibility package, but this is not a >> long-term solution, and I have no confidence that these projects will be >> sustainably maintained in the future. >> > > typer-0.4.0 got released today. > https://github.com/tiangolo/typer/releases/tag/0.4.0 > > I think it addresses the above issue related to click 7.x compatibility package, > > As per https://github.com/tiangolo/typer/issues/313#issuecomment-908181587 > ``` > I just released Typer 0.4.0, which is compatible with both Click 7 and Click 8. > ``` > I hope it helps. > > Thank you for maintaining it. > > Thanks, > > Chandan Kumar >

1 0

Using reverse week deps for Python interpreters and tox (Supplements instead of Recommends)?
by Miro Hrončok 25 Aug '21

25 Aug '21

Hello Pythonistas. Currently, the tox package has: # Recommend "all the Pythons" Recommends: python2.7 Recommends: python3.6 Recommends: python3.7 Recommends: python3.8 Recommends: python3.9 Recommends: python3.10 Recommends: pypy2-devel Recommends: pypy3-devel Recommends: python2-devel Recommends: python3-devel Every time we add or remove a Python interpreter, we need to change the list: E.g. https://src.fedoraproject.org/rpms/python-tox/c/7220117b812d3b5b009b3b1170e… What if we added this to all interpreters that work with our tox instead? Supplements: tox That way: - When we introduce a new interpreter, tox starts to pull it by default right away. - When different Fedoras (or even EPELs) have different interpreter sets, we don't need to divert the tox spec. OTOH: - When we add a new interpreter that Supplements tox, we would still need to adapt tox's CI config to include it. Maybe we could adapt the CI tests for tox to automatically test with all interpreters that supplement it. WDYT? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

2 1

Intent to retire python-typer and python-typer-cli
by Ben Beasley 20 Aug '21

20 Aug '21

Unless someone convinces me of another plan, I intend to retire python-typer and python-typer-cli in F35 and Rawhide in one week (2021-08-27). I myself introduced these two packages to Fedora quite recently (https://bugzilla.redhat.com/show_bug.cgi?id=1964742, https://bugzilla.redhat.com/show_bug.cgi?id=1974118). No other packages currently depend on them. Upstream was in a period of inactivity that was not too worrisome at the time, but has become much more concerning as they have not responded at all to issues or PR’s on this project and have not made the necessary (nontrivial) changes to work with the new major release (8.x) of python-click. Please see https://github.com/tiangolo/typer/issues/313 for an overview of the situation and links to additional relevant issues. It might be possible to sustain these two packages in Fedora 35 by introducing a click 7.x compatibility package, but this is not a long-term solution, and I have no confidence that these projects will be sustainably maintained in the future.

1 0

pypy3 renamed to pypy3.7 on Fedora 35+, also available in Fedora 33/34
by Miro Hrončok 17 Aug '21

17 Aug '21

Hello PyPyistas, we have renamed the pypy3 package to pypy3.7 (both the component and the "binary" package) on Fedora 35+. The package no longer installs to /usr/lib64/pypy3-7.x/ but rather to /usr/lib64/pypy3.7/. *What is this good for?* When PyPy 3 was updated from Python 3.N to 3.N+1, traditionally we have only updated it in Rawhide (and Branched), not to do a backward-incompatible update in stable Fedoras. With this renaming, you can now¹ install pypy3.7 on all Fedoras, despite pypy3 being 3.6 on Fedora 33 and 34. ¹ (The builds are still running, expect an update in Bodhi later today.) Once PyPy 3.8 is released, we can introduce it to all Fedora versions. *Warning to Rawhide/Fedora 35 users* If you already used the pypy3 package with PyPy 3.7, the pypy3.7 package will obsolete it. However, the installation paths are different, so you will need to re-create your PyPy 3 virtual environments. *Details* (feel free to ignore the rest of this email) During a lifetime of one stable Fedora release, you will get: - pypy3.N that provides pypy3 and has /usr/bin/pypy3 - pypy3.N+c introduced later in the lifetime E.g. for Fedora 35: - pypy3.7 that provides pypy3 and has /usr/bin/pypy3 - pypy3.8 (or newer) might be introduced in the future For Fedora 33 and 34, there is a transition period: - pypy3 provides pypy3.6 and has /usr/bin/pypy3 - pypy3.7 was just introduced - pypy3.8 (or newer) might be introduced in the future See for example on Fedora 33: $ rpm -qa | grep pypy3 pypy3-libs-7.3.1-6.fc33.x86_64 pypy3-7.3.1-6.fc33.x86_64 pypy3-devel-7.3.1-6.fc33.x86_64 pypy3.7-libs-7.3.4-4.fc33.x86_64 pypy3.7-7.3.4-4.fc33.x86_64 pypy3.7-devel-7.3.4-4.fc33.x86_64 $ pypy3.6 --version Python 3.6.9 (831ff17f8cd1, May 26 2021, 11:41:48) [PyPy 7.3.1 with GCC 10.3.1 20210422 (Red Hat 10.3.1-1)] $ pypy3.7 --version Python 3.7.10 (8dd9fc18a6f0, Aug 11 2021, 06:30:36) [PyPy 7.3.4 with GCC 10.3.1 20210422 (Red Hat 10.3.1-1)] $ pypy3 --version Python 3.6.9 (831ff17f8cd1, May 26 2021, 11:41:48) [PyPy 7.3.1 with GCC 10.3.1 20210422 (Red Hat 10.3.1-1)] Note that we *do not* plan to maintain old PyPy versions indefinitely, we plan to retire them from Rawhide/Branched as soon as new versions arrive and only keep them alive until stable Fedoras goes EOL. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

2 3

requesting help to update spyder
by Mukundan Ragavan 15 Aug '21

15 Aug '21

Hi, I am trying to update spyder on rawhide and F35. The main issue I have is that pyqt requirements are strict. From the setup file, 'pyqt5<5.13', 'pyqtwebengine<5.13', Fedora has 5.15.x. If I relax QT versions, built and launch spyder, I get this error and spyder fails to launch. scaled(self, int, int, aspectRatioMode: Qt.AspectRatioMode = Qt.IgnoreAspectRatio, transformMode: Qt.TransformationMode = Qt.FastTransformation): argument 1 has unexpected type 'float' scaled(self, QSize, aspectRatioMode: Qt.AspectRatioMode = Qt.IgnoreAspectRatio, transformMode: Qt.TransformationMode = Qt.FastTransformation): argument 1 has unexpected type 'float' Spec and patches can be seen here - https://copr-dist-git.fedorainfracloud.org/cgit/nonamedotc/spyder5dev/spyde… Any help to get this sorted out will be greatly appreciated. Thanks, Mukundan. -- GPG Key: E5C8BC67

5 5

Macro to smoke-test-import a Python module in %check
by Miro Hrončok 04 Aug '21

04 Aug '21

Hello Python RPM packagers, based on some discussion in the "F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)" thread [0], I've drafted a macro that can help to test-import a Python module in %check when no other tests exist or are when they cannot be executed during build [1]. The semantics is quite simple: %check %py3_check_import mymodule mymodule.submodule When all listed modules are successfully imported, "nothing happens", when at lest one fails to import, the entire build fails. The above line is translated very-roughly to `python3 -c 'import mymodule, mymodule.submodule'` (see the implementation [0] for more accurate representation). Given the Python semantics, it is possible to use commas as module separators as well (but no parentheses). The %buildroot's %pythn3_site{lib,arch} is added to PYTHONPATH. The runtime dependencies are obviously needed for this to work, so they need to be manually BuildRequired or even better, generated in %generate_buildrequires via `%pyproject_buildrequires -r` to use this macro. The macro can be used repeatedly when importing multiple modules at once is undesired (e.g. when only one module can be imported from the same Python interpreter): %check %py3_check_import mymodule.either %py3_check_import mymodule.or Before I merge this and backport to all Fedoras and EPELs, I'd like to know: - Do you have better ideas for the macro name? - Do you have better ideas for the macro semantics? [0] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… [1] https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/99 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

4 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

python-devel August 2021