python-devel October 2021

python-devel@lists.fedoraproject.org

12 participants
10 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

HEADS UP: Slightly more robust Python Requires generated by RPM
by Miro Hrončok 01 Nov '21

01 Nov '21

Hello Pythonistas, just a heads up that in rawhide, the automatically generated requirements on Python packages, e.g. python3.Xdist(DISTNAME), ar enow generated in more strict form. If a package required "PyYAML < 6", it was previously generated as: python3.10dist(pyyaml) < 6 Which was satisfied by PyYAML 6.0b1 (python3.10dist(pyyaml) 6~b1). From now on, it will be generated as: python3.10dist(pyyaml) < 6~ Which will not be satisfied by any alpha/beta/rc release of PyYAML 6. There are other related differences as well neither of which should release break anything except for when dealing with pre-releases, it is now more strict. Details: https://bugzilla.redhat.com/show_bug.cgi?id=2014616 Any new requires will start happening as the packages are rebuilt, so as always, please check your packages for installability when you build them and let me know if something behaves in a weird way. Identical changes to %pyproject_buildrequires will land soon (on all releases, as maintaining bit-by-bit requires compatibility is not necessary there). Thanks to Gordon for improving the generators. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

5 11

Introducing %pyproject_check_import, checks importability of all found Python modules
by Karolina Surma 29 Oct '21

29 Oct '21

Hello, the new versions of pyproject-rpm-macros (0-49) and python-rpm-macros (3.10-12) landed in Rawhide. Updates are available for older Fedoras: F35: https://bodhi.fedoraproject.org/updates/FEDORA-2021-fd8d8c5f66 F34: https://bodhi.fedoraproject.org/updates/FEDORA-2021-22b68be2d5 F33: https://bodhi.fedoraproject.org/updates/FEDORA-2021-d085ce09ef They bring some enhancements I'd like to briefly describe here: pyproject-rpm-macros A new macro, %pyproject_check_import, has been introduced. You'll benefit from it if you use %pyproject_save_files in your specfile. It can play a role of a smoke test in cases when the upstream tests suite doesn't exist or can't be used. When %pyproject_save_files is invoked, it creates a list of all valid and public (i.e. not starting with `_`) importable module names found in the package. This list is then used by %pyproject_check_import to perform an import check for each listed module. When a module fails to import, the build fails. Call %pyproject_check_import in %check to perform a test on all found modules: %check %pyproject_check_import %pyproject_check_import can be modified with -t flag, which performs a check only on top-level module names (i.e. not containing dot): %check %pyproject_check_import -t %pyproject_check_import can be modified with -e flag, which excludes the module names matching given glob(s) from the import check: %check %pyproject_check_import -e '*.test*' -e '*.config' A more detailed explanation of the macro can be found in the project's README. [0]. The %pyproject_check_import macro calls %py3_check_import underneath, which has received a few improvements as well. To use the %pyproject_check_import macro, make sure to have the most recent python3-rpm-macros installed (for various reasons, a versioned dependency is *not* used) -- not only in the buildroot but also on the host (if installed at all). python-rpm-macros The API of %py3_check_import was extended to support the %pyproject_check_import use case. 3 new flags were added: -t (top-level) -e (exclude glob(s)) -f (a path to a file with qualified module names, separated with newlines) The -e and -f options can be used repeatedly. We expect this new API to be used mostly via %pyproject_check_import, but it is not the only option. When using %py3_check_import, you don't need to invoke %pyproject_save_files. Happy packaging, Karolina Surma [0] https://src.fedoraproject.org/rpms/pyproject-rpm-macros/blob/rawhide/f/READ…

1 0

Packaging autorandr
by Peter Kotvan 23 Oct '21

23 Oct '21

Hello folks! I'd like to package the autorandr <https://github.com/phillipberndt/autorandr> project for Fedora. This would be my first python package so I'd like to ask some questions. Firstly the project already contains a spec <https://github.com/phillipberndt/autorandr/blob/master/contrib/packaging/rp…> file. However I'm not sure whether it could be used without any modifications. For example the %install section doesn't contain %pyproject_install but rather uses make and install commands. But maybe it's the correct approach since the package should contain not just python files and executables but also systemd unit and udev rule. I'd like to ask for guidance on how to approach this, especially whether the original spec file is usable or if I should create a new one according to Python Packaging Guidelines <https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/>. Thanks in advance and kind regards. -- Peter Kotvan

3 2

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

HEADS UP: pip 21.3 does in-tree builds by default now, %{_pyproject_builddir}/ .pyproject-builddir will be empty
by Miro Hrončok 15 Oct '21

15 Oct '21

Hello Pythonistas. We are about to update pip in rawhide to 21.3. It does in-tree builds by default and hence if your package sues pyproject-rpm-macros, you won't find it the built stuff in %{_pyproject_builddir} anymore. The following packages will need changes: python-numcodecs.spec 72:PYTHONPATH=$(ls -d %{_pyproject_builddir}/pip-req-build-*/build/lib.%{python3_platform}-%{python3_version}) sphinx-build-3 docs html python-pikepdf.spec 60:PYTHONPATH=$(ls -d %{_pyproject_builddir}/pip-req-build-*/build/lib.%{python3_platform}-%{python3_version}) sphinx-build-3 . ../html python-matplotlib.spec 302:PYTHONPATH=$(ls -d %{_pyproject_builddir}/pip-req-build-*/build/lib.%{python3_platform}-%{python3_version}) \ rpm-specs/python-pydata-sphinx-theme.spec 81:PYTHONPATH=$(ls -1d $PWD/.pyproject-builddir/pip-req-build-*) make -C docs html Note that %{_pyproject_builddir} was prefixed with underscore exactly for this reason (packages that use it might need changes). With pip 21.3+, replacing %{_pyproject_builddir}/pip-req-build-*/build with ${PWD}/build should do. However, that will loose compatibility with older pip. We only plan to do this change in rawhide. You can use this copr for testing: https://copr.fedorainfracloud.org/coprs/churchyard/pip-21.3/ (Pull Request integration is set, so if you send a PR to your pckage, you can observe the results in https://copr.fedorainfracloud.org/coprs/churchyard/pip-21.3/builds/?dirname…:<number> -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

1 0

Python 3.10 in Fedora 36+: sysconfig's "posix_prefix" install scheme now has /usr/local
by Miro Hrončok 10 Oct '21

10 Oct '21

Hello Pythonistas, since Fedora 27, we have been patching Python to install packages to /usr/local/lib(64)/python3.X/site-packages if not in rpmbuild: https://fedoraproject.org/wiki/Changes/Making_sudo_pip_safe The patch was a pragmatic hack in the distutils module that proved to be working quite reliably over the years. Unfortunately, the distutils module is deprecated and is going to be removed from Python 3.12: https://www.python.org/dev/peps/pep-0632/ Working with the upstreams of setuptools, pip, and Python, as well as other Linux distros Python maintainers (Arch, Debian), we have now changed the way the patch works to patch the sysconfig module instead, changing the posix_prefix install scheme to use /usr/local paths. See https://discuss.python.org/t/pep-632-deprecate-distutils-module/5134/104 for details. This change is aligned with the upstream plan for Python 3.11 to offer distributors a way to supply their installation schemes to sysconfig: https://bugs.python.org/issue43976 Nothing should change for Fedora packages. If you encounter problems, do let us know and we'll try to help solve them. Software that reads the posix_prefix install_scheme on runtime to figure out where to install stuff should behave the right way by default. OTOH software that reads it to figure out where to load stuff from might need changes, see e.g. the change we did in dnf: https://github.com/rpm-software-management/dnf/pull/1782 Relevant commit: https://src.fedoraproject.org/rpms/python3.10/c/47935cfb9870 Bodhi update: https://bodhi.fedoraproject.org/updates/FEDORA-2021-31c7a2fca8 We might later introduce this to older Python versions as well, but we are not planning to backport this to older Fedora releases. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

1 2

where I have a %py_provides example ?
by Sérgio Basto 10 Oct '21

10 Oct '21

https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_provides… the example doesn't provides %py_provides macro also I don't find mentions how replacing of %python_provide %py_provides Thank you -- Sérgio M. B.

2 1

Self Introduction: Titouan Bénard
by TItouan Bénard 09 Oct '21

09 Oct '21

Hi, I'm Titouan, I have made some contribution in open source and now I would like to contribute in Fedora. I like django, drf (Django rest framework), uikit, pygobject. I want to join the Python SIG. Thanks Titouan Bénard

1 0

Migrate python3-language-server upstream to the version maintained by the community
by Mairo Paul Rufus 06 Oct '21

06 Oct '21

Currently python3-language-server upstream is https://github.com/palantir/python-language-server which is currently unmaintained, this is a proposal to move that to https://github.com/python-lsp/python-lsp-server which is a community-maintained fork.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

python-devel October 2021