Considering the rationale you’ve laid out, I don’t have any complaints about deprecating %{pyproject_build_lib}. I’m indifferent to the possible addition of a setuptools-specific macro, assuming the setuptools build directory is expected to stop changing frequently.
I tested the proposed replacements in a handful of packages that used %{pyproject_build_lib} (python-asyncpg, python-cmake-build-extension, python-cyipopt, and python-ezdxf). In python-cmake-build-extension, I need to run test executables from the build directory (admittedly an unusual situation), and removing %{pyproject_build_lib} actually simplified the spec file, since I no longer needed to consider a colon-separated list of *possible* build directories. The adjusted spec files for these packages worked as expected on F37–F39.
On 3/8/23 06:09, Miro Hrončok wrote:
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?