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?
>