Hello Pythonistas,
pyproject-rpm-macros 1.11.0 is available in Rawhide + updates-testing for older releases.
https://bodhi.fedoraproject.org/updates/?packages=pyproject-rpm-macros
I plan to sync it to c9s eventually early next year.
It contains one new feature and several smaller bugfixes:
The new -l/-L flag to %pyproject_save_files ===========================================
As said by Maxwell G on this list [1]:
%pyproject_save_files automatically handles marking license files with %license when a build backend installs them into a package's dist-info directory and the License-File header is specified in the METADATA file. Currently, only setuptools and hatchling meet this criteria. Notably, poetry and flit do not support this. They will install license texts into the dist-info directory, but they do not add the License-File metadata. The License-File tag is not standardized, and discussion on PEP 639 which defines this standard has stalled. I believe relying on this feature is a problem, as if a project changes build systems or some other config and a packager doesn't realize, suddenly the license file won't be marked with %license or even worse, not installed at all. Since the pyproject macros read the build backend from pyproject.toml without packagers having to manually specify anything (which is generally great!), this situation seems likely to occur.
You can now use `%pyproject_save_files -l` to assert at least one license file was detected and marked as %license. This is good in case you want a protection from an accidental silent drop of the %license file in a next release.
Note that the -l flag only asserts *at least one license file was detected*. It can still mean one of multiple files are silently dropped during a package upgrade, but that's unlikely to happen for unrelated reasons (such as a change of a build backend upstream).
For the time being, this assertion is opt-in only. Use `%pyproject_save_files -L` if you list the %license file manually and you would like to explicitly opt-out from this check in case it ever becomes the default (no such plan exists for the time being).
(Note that this still needs to be documented in the Python packaging guidelines.)
Prevent incorrect usage of %pyproject_buildrequires -R with -x/-e/-t ====================================================================
Using `%pyproject_buildrequires -R` with -x, -t, or -e previously silently discarded the -R option. Combining either of the flags with -R is actually not possible and will now error properly.
https://bugzilla.redhat.com/2244282
Show a better error message when %pyproject_install finds no wheel ==================================================================
When there is no wheel to install (e.g. when you forget to run %pyproject_wheel), the underlying pip error message was leaking:
ERROR: You must give at least one requirement to install (maybe you meant "pip install /builddir/build/BUILD/Pello-1.0.4/pyproject-wheeldir"?)
It has been explicitly changed to:
ERROR: %pyproject_install found no wheel in %{_pyproject_wheeldir} /builddir/build/BUILD/Pello-1.0.4/pyproject-wheeldir
https://bugzilla.redhat.com/2242452
Fix %pyproject_buildrequires -w when build backend is installed and pip isn't =============================================================================
Packages using `%pyproject_buildrequires -w` would fail to build if the build backend was already (manually) installed before pip.
This was happening e.g. when testing a local version of the RPM with the build backend and running something like:
$ mock init $ mock install ../my-rpms/pytohn3-hatchling-1.2.3-1.fc50.noarch.rpm $ fedpkg mockbuild -N
But it was also possible to achieve with manual BuildRequires:
BuildRequires: pytohn3-hatchling ... %generate_buildrequires %pyproject_buildrequires -w
The %pyproject_buildrequires macro generated a BuildRequires on pip, but it attempted to build a wheel using pip before the generated pip dependency was installed. This has now been fixed and the macro will "restart" in case pip is not yet available to build the wheel.
https://bugzilla.redhat.com/2169855
-----------------------------------
Happy packaging.
Special thanks to Maxwell G, Karolina Surma, and Benjamin Beasley for help with this release.
[1] https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproje...
python-devel@lists.fedoraproject.org