pyproject-rpm-macros 1.2.0: Improved support for alternate build backends (e.g. hatchling)
Hello Pythonistas.
I am glad to announce the release of pyproject-rpm-macros 1.2.0.
The new version is available in rawhide and waits for your karma in updates-testing for older Fedoras:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-80586f3147 https://bodhi.fedoraproject.org/updates/FEDORA-2022-d4047b4440 https://bodhi.fedoraproject.org/updates/FEDORA-2022-64c16b2d38
Update for c9s will follow shortly.
What's new since 1.0.0 ======================
Version 1.1.0 introduced support for nested directories in the *.dist-info metadata directory. This was not needed before, as there was no known build backend creating such directories. However, hatchling [1] does that and more and more packages in Fedora are using it. This is a backward-compatible change and you should not need to change anything unless you listed files in nested directories manually -- this workaround can now be removed. The removal is optional: if not removed RPM will only warn about files listed twice.
More importantly, version 1.2.0 added support for reading runtime dependencies via %pyproject_buildrequires for build backends not supporting the PEP 517 prepare_metadata_for_build_wheel [2] (such as hatchling as well). Until now, when you wanted to get the runtime dependencies (%pyproject_buildrequires -r: the default) or use other functionality depending on it (%pyproject_buildrequires -x/-t/-e) and the backend did not support it, it failed -- you had to disable it by using -R.
However, PEP 517 explicitly says:
""" If a build frontend needs this information and the method is not defined, it should call build_wheel and look at the resulting metadata directly. """
%pyproject_buildrequires now provisionally support exactly that with the new -w flag. When -w is used, the wheel is built and the macro looks at the resulting metadata directly. Read all about it in the README [3] in the "Adding run-time and test-time dependencies" section. A short tl;dr here:
- due to technical limitations, the wheel is built twice - you can omit %build/%pyproject_wheel to avoid building it for the 3rd time - don't patch/sed between %pyproject_buildrequires -w and %pyproject_wheel - the -w flag builds the wheel even when the hook exists
As this is a provisional functionality, the API and/or behavior might change in the future. Hence it is not yet mentioned in the packaging guidelines. You are allowed to use it if you are prepared for potential breakage in the future.
Where to get help =================
Report bugzillas [4] or write to this list [5] if you encounter any problems or if you need help.
[1] https://pypi.org/project/hatchling/ [2] https://peps.python.org/pep-0517/#prepare-metadata-for-build-wheel [3] https://src.fedoraproject.org/rpms/pyproject-rpm-macros/blob/rawhide/f/READM... [4] https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=pypro... [5] Fedora Python SIG python-devel@lists.fedoraproject.org
Happy packaging,
On Fri, May 6, 2022, at 05:07, Miro Hrončok wrote:
Hello Pythonistas.
I am glad to announce the release of pyproject-rpm-macros 1.2.0.
The new version is available in rawhide and waits for your karma in updates-testing for older Fedoras:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-80586f3147 https://bodhi.fedoraproject.org/updates/FEDORA-2022-d4047b4440 https://bodhi.fedoraproject.org/updates/FEDORA-2022-64c16b2d38
Update for c9s will follow shortly.
I haven't tested the fancy new `-w` option, but the macros work fine on my existing RPM builds in mock on rawhide/f36. 🎉
On 06. 05. 22 13:55, Major Hayden wrote:
On Fri, May 6, 2022, at 05:07, Miro Hrončok wrote:
Hello Pythonistas.
I am glad to announce the release of pyproject-rpm-macros 1.2.0.
The new version is available in rawhide and waits for your karma in updates-testing for older Fedoras:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-80586f3147 https://bodhi.fedoraproject.org/updates/FEDORA-2022-d4047b4440 https://bodhi.fedoraproject.org/updates/FEDORA-2022-64c16b2d38
Update for c9s will follow shortly.
I haven't tested the fancy new `-w` option, but the macros work fine on my existing RPM builds in mock on rawhide/f36. 🎉
BTW if you do use the fancy new `-w` option (even in mock), make sure your local installation was updated (or that the package is not installed at all locally). Otherwise you won't be able to create the SRPM.
Thank you for working on this! I’m excited that this approach turned out to be reasonably practical. This update makes it vastly more practical to deal with packages that use the hatchling backend. I’ve already updated python-hatchling itself and a handful of other packages to use the new features, and everything is working great so far.
On 5/6/22 06:07, Miro Hrončok wrote:
Hello Pythonistas.
I am glad to announce the release of pyproject-rpm-macros 1.2.0.
The new version is available in rawhide and waits for your karma in updates-testing for older Fedoras:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-80586f3147 https://bodhi.fedoraproject.org/updates/FEDORA-2022-d4047b4440 https://bodhi.fedoraproject.org/updates/FEDORA-2022-64c16b2d38
Update for c9s will follow shortly.
What's new since 1.0.0
Version 1.1.0 introduced support for nested directories in the *.dist-info metadata directory. This was not needed before, as there was no known build backend creating such directories. However, hatchling [1] does that and more and more packages in Fedora are using it. This is a backward-compatible change and you should not need to change anything unless you listed files in nested directories manually -- this workaround can now be removed. The removal is optional: if not removed RPM will only warn about files listed twice.
More importantly, version 1.2.0 added support for reading runtime dependencies via %pyproject_buildrequires for build backends not supporting the PEP 517 prepare_metadata_for_build_wheel [2] (such as hatchling as well). Until now, when you wanted to get the runtime dependencies (%pyproject_buildrequires -r: the default) or use other functionality depending on it (%pyproject_buildrequires -x/-t/-e) and the backend did not support it, it failed -- you had to disable it by using -R.
However, PEP 517 explicitly says:
""" If a build frontend needs this information and the method is not defined, it should call build_wheel and look at the resulting metadata directly. """
%pyproject_buildrequires now provisionally support exactly that with the new -w flag. When -w is used, the wheel is built and the macro looks at the resulting metadata directly. Read all about it in the README [3] in the "Adding run-time and test-time dependencies" section. A short tl;dr here:
- due to technical limitations, the wheel is built twice - you can omit %build/%pyproject_wheel to avoid building it for the 3rd time - don't patch/sed between %pyproject_buildrequires -w and %pyproject_wheel - the -w flag builds the wheel even when the hook exists
As this is a provisional functionality, the API and/or behavior might change in the future. Hence it is not yet mentioned in the packaging guidelines. You are allowed to use it if you are prepared for potential breakage in the future.
Where to get help
Report bugzillas [4] or write to this list [5] if you encounter any problems or if you need help.
[1] https://pypi.org/project/hatchling/ [2] https://peps.python.org/pep-0517/#prepare-metadata-for-build-wheel [3] https://src.fedoraproject.org/rpms/pyproject-rpm-macros/blob/rawhide/f/READM... [4] https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=pypro... [5] Fedora Python SIG python-devel@lists.fedoraproject.org
Happy packaging,
python-devel@lists.fedoraproject.org
-
Ben Beasley -
Major Hayden -
Miro Hrončok