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=pyproject-rpm-macros
or email this mailing list <python-devel@lists.fedoraproject.org>.
Happy packaging,
--
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
