Hi Johannes, cross-posting to python@lists.opensuse.org Am 20.07.22 um 13:54 schrieb Johannes Kastl:

Hi all,

is there a proper/recommended way to build python packages and not run into the deprecation warning for using distutils or setup.py install?

e.g. https://build.opensuse.org/build/systemsmanagement/openSUSE_Tumbleweed/x86_6...:

...

[   88s] /home/abuild/rpmbuild/BUILD/ansible-2.9.27/setup.py:12: DeprecationWarning: The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives [   88s]   from distutils.command.build_scripts import build_scripts as BuildScripts

...

[  402s] /usr/lib/python3.10/site-packages/setuptools/command/install.py:34: SetuptoolsDeprecationWarning: setup.py install is deprecated. Use build and pip and other standards-based tools. [  402s]   warnings.warn(

Does not seem to be a pressing issue, but if there is an easy way to fix this (in the package, not upstream) then I could do this while touching the python packages I need to touch currently...

Kind Regards, Johannes

The proper way to fix the first one it is to replace distutils with setuptools upstream.  I understand that this is not applicable to legacy ansible-2.9.27. At the very least, you should import setuptools before distutils in a patch for the package's setup.py. Note that setuptools 60+ hijacks distutils, which already produces problems in other packages: - https://github.com/pypa/setuptools/issues/3143 It would be great if you can harden your package against the setuptools update that is currently staged and already present in devel:languages:python. On a related note: The setuptools update broke at least 20 packages in Ring1. All of those 20 packages have fixes in the submit pipeline, except for ceph (https://bugzilla.suse.com/show_bug.cgi?id=1201604). If the update breaks too many non-Ring 1 packages, we might need a python-setuptools58 in the distribution. StevenK, Matej, any thoughts? The second message can be silenced by migrating from setup.py install (%python_install) to installing a wheel (%pyproject_install) which either has been built by %pyproject_wheel beforehand or downloaded from PyPI. The latter only works for pure  "none-any.whl" wheels without any precompiled binaries and if you don't need test data from an sdist or scm repository, which is not present in the wheel. In the long term, the setup.py install call will have to be replaced by some PEP517 compliant install scheme (The pip install call from %pyproject_install, or some other tool like `python-install`): https://trello.com/c/wMWZ7lw5/122-setuppy-install-replacement - Ben