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?

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
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

Reply via email to