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?
_______________________________________________
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
