Re: Let's deprecate the %{pyproject_build_lib} macro... ?

Hello. The %{pyproject_build_lib} macro is a *provisional* macro from pyproject-rpm-macros. It was added to solve the problem of out-of-tree pip builds. From the pyproject-rpm-macros README: """ Sometimes, it is desired to be able to import the just-built extension modules in the %build section, e.g. to build the documentation with Sphinx.   %build   %pyproject_wheel   ... build the docs here ... With pure Python packages, it might be possible to set PYTHONPATH=${PWD} or PYTHONPATH=${PWD}/src. However, it is a bit more complicated with extension modules. The location of just-built modules might differ depending on Python version, architecture, pip version, etc. Hence, the macro %{pyproject_build_lib} exists to be used like this:   %build   %pyproject_wheel   PYTHONPATH=%{pyproject_build_lib} ... build the docs here ... """ When this macro was introduced, the built extension module lived in a folder like /builddir/build/BUILD/%{name}-%{version}/.pyproject-builddir/pip-req-build-xxxxxxxx/build/lib.linux-x86_64-3.10, hence it made sense to include in the pyproject-rpm-macros and call it %pyproject_something. ------------------------------------------------------------ Today, on Rawhide, pip default to in-tree-builds and the value for extension modules will most likely be:   $PWD/build/lib.%{python3_platform}-cpython-%{python3_version_nodots} And for pure Python:   $PWD/build/lib And it turns out, the value is setuptools-specific, see https://bugzilla.redhat.com/show_bug.cgi?id=2176393 Other build backends might store the built extension modules elsewhere or simply pack the pure Python files into wheel directly from the source tree. ------------------------------------------------------------ In Rawhide, 41 packages use PYTHONPATH="%{pyproject_build_lib}" and 2 packages have a comment with %%{pyproject_build_lib} in them. Considering the macro  - is not build-backend-agnostic, and  - is not so much needed as it once was I propose we deprecate it with no further fixes going in, but no scheduled removal. The 41 packages can be fixed once Fedora 36 goes EOL by expanding the macro to the values above, or if desired, we could macronize this in pythohn3-setuptools as %{setuptools_build_lib}. One problem is that the macro is unfortunately still needed on EL 9. Thoughts?