Hello Pythonistas.
We have released a new version of pyproject-rpm-macros 1.4.0.
The version is available in Rawhide and ELN, and updates are ready for all older Fedora releases.
https://bodhi.fedoraproject.org/updates/?packages=pyproject-rpm-macros
CentOS 9 Stream update is planned as well.
There are some minor documentation and CI changes, but the important 2 new features are:
## Packages using the hatchling backend now correctly mark %license files
The support for %license files in %pyproject_save_files/%{pyproject_files} is based on a *draft PEP 639*:
https://peps.python.org/pep-0639/
For a time, the only known backend that supported the PEP was setuptools. Packages using setuptools correctly marked %license files in %{pyproject_files}.
However, since the PEP is not yet finished, is still occasionally changes. The PEP was updated recently in a way that made pyproject-rpm-macros non-complaint. It introduced a *Root License Directory*, a subdirectory of the dist-info meatdata directory.
In the meantime a new build backend (hatchling 1.9.0+) implemented support for the license files following the updated PEP. As a result, packages using the hatchling backend did not mark %license files in %{pyproject_files} correctly.
pyproject-rpm-macros 1.4.0 added support for the current version of the PEP while maintaining support for the old way (for compatibility with setuptools).
Packages using the hatchling backend will correctly mark %license files in %{pyproject_files}. Note that only hatchling 1.9.0+ (available on Fedora 36+) supports this. (Other build backends that support the current version of PEP 639 might also exist, but we are not aware of them.)
For details, see https://bugzilla.redhat.com/2127946
## %pyproject_check_import now only imports what matches %pyproject_save_files
If a packager wants to use %pyproject_check_import they need to use %pyproject_save_files first to generate a list of known modules to check-import.
Previously, all non-underscroed modules were always check-imported with %pyproject_check_import. That may have lead to confusing scenarios when mutliple top-level modules were present:
%install %pyproject_install # <- installs modules "one" and "two" %pyproject_save_files one # <- module called "two" is skipped
%check %pyproject_check_import # <-- this was also check-importing "two"
pyproject-rpm-macros 1.4.0 filters the list of modules to check-import to only try importing modules that match:
%install %pyproject_install # <- installs modules "one" and "two" %pyproject_save_files one # <- module called "two" is skipped
%check %pyproject_check_import # <-- this will no longer check-import "two"
Note that we do not recommend having packages with more than one non-underscored top-level module, but some upstreams unfortunately do that.
For details, see http://bugzilla.redhat.com/2127958
In case of trouble, file a bug at https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=pypro... or email this mailing list python-devel@lists.fedoraproject.org.
Happy packaging,