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/README.md
[4]
https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=pyproject-rpm-macros
[5] Fedora Python SIG <python-devel@lists.fedoraproject.org>
Happy packaging,
_______________________________________________
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 on the list, report it:
https://pagure.io/fedora-infrastructure
