Hello, we have just released pyproject-rpm-macros 0-46 with new features and breaking changes (2 affected Fedora packages, python-platformdirs and python-shellingham).
F35: https://bodhi.fedoraproject.org/updates/FEDORA-2021-a33e4b0558
F34: https://bodhi.fedoraproject.org/updates/FEDORA-2021-fcf5e2adc6
F33: https://bodhi.fedoraproject.org/updates/FEDORA-2021-3d06d86fe9
We aim to release version 1 before Fedora 35 is released: That should remove the "provisional" status of the macros: we are extensively probing the design decisions and plan to maintain a stable interface and behavior after that.
tl;dr version:
%pyproject_buildrequires now supports x.* versions.
In %pyproject_buildrequires, invalid requirements now *fail* the build.
%pyproject_buildrequires fallbacks to setuptools only if setup.py exists.
The requirements files parser is now more robust.
%pyproject_save_files now escapes weird characters.
%pyproject_save_files marks license files with %license.
The %{_pyproject_ghost_distinfo} and %{_pyproject_record} macros are private.
Details below:
---------------
%pyproject_buildrequires now supports x.* versions.
When a project requires e.g. "pkg==6.*", %pyproject_buildrequires now correctly handles that by requiring "pytohn3dist(pkg) >= 6 with pytohn3dist(pkg) < 7".
---------------
In %pyproject_buildrequires, invalid requirements now *fail* the build.
Previously, they were skipped with a warning. Only one package in Fedora is affected and a PR exists (python-platformdirs#1).
Failing the build for dependencies that cannot be processed via Python tools (such as pip) is harmless: The package would eventually fail to build later in the process anyway. However, some dependency declarations work with pip while we cannot process them via the macros. From the README:
When a dependency is specified via an URL or local path, for example as:
https://github.com/ActiveState/appdirs/archive/8eacfa312d77aba28d483fbfb6f6f... /some/path/foo-1.2.3.tar.gz git+https://github.com/sphinx-doc/sphinx.git@96dbe5e3
The %pyproject_buildrequires macro is unable to convert it to an appropriate RPM requirement and will fail. If the URL contains the packageName @ prefix as specified in PEP 508, the requirement will be generated without a version constraint:
appdirs@https://github.com/ActiveState/appdirs/archive/8eacfa312d77aba28d483fbfb6f6f... foo@file:///some/path/foo-1.2.3.tar.gz
Will be converted to:
python3dist(appdirs) python3dist(foo)
Alternatively, when an URL requirement parsed from a text file given as positional argument to %pyproject_buildrequires contains the #egg=packageName fragment, as documented in pip's documentation:
git+https://github.com/sphinx-doc/sphinx.git@96dbe5e3#egg=sphinx
The requirements will be converted to package names without versions, e.g.:
python3dist(sphinx)
However upstreams usually only use direct URLs for their requirements as workarounds, so be prepared for problems.
------------
%pyproject_buildrequires fallbacks to setuptools only if setup.py exists.
In line with the recent development of pip (and build), when the build backend is not specified (e.g. pyproject.toml is missing or does not specify it) the setuptools.build_meta.__legacy__ build backend is only used if setup.py exists.
Projects without setup.py that intent to use setuptools need to explicitly declare it in pyoproject.toml or add a setup.py stub, see e.g. python-shellingham#5, the only affected Fedora package.
---------------
The requirements files parser is now more robust.
The %pyproject_buildrequires macro accepts requirements files as optional position arguments. With this release, the parser for the files (also used for tox dependencies) is more robust and should process comments, escaped newlines and environment variables better than ever.
However, the parser is not (yet) 100% compatible with `pip install -r <file>` behavior (and might as well never be). If you encounter incompatibilities, please let us know.
---------------
%pyproject_save_files now escapes weird characters.
When a path contains spaces (incl. newlines), quotes (") or percentage signs (%), it is now correctly escaped by %pyproject_save_files.
Note that due to the limitations of RPM, we are unable to represent a path with both spaces and quotes. An error is raised when that happens, instead of producing wrong results.
---------------
%pyproject_save_files marks license files with %license.
PEP 639 (still a draft) introduces a new metadata field for license files (the License-File field). Setuptools 57+ generate the field from the license_file(s) setup options. %pyproject_save_files newly recognizes this field and marks the listed files with the %license tag. Other build backends might follow later.
If your package supports this, you no longer need to list the license file manually. I recommend using `rpm -ql --licensefiles` to verify this before removing the manually listed LICENSE file.
Note that in Fedora 33 and 34 we don't have setuptools 57+, so I only recommend doing this for packages that don't do merges to stable Fedoras.
---------------
The %{_pyproject_ghost_distinfo} and %{_pyproject_record} macros now start with an underscore to indicate they are "private": You should not use them in the spec file unless working around some bug in pyproject-rpm-macros. If you ever need to use the macros (or their value) in spec, consider contacting us first.