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.fedoraproject.org/thread/YDIHALW766GRSYU3GL635QER2MQABML6/

--
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