On Fri, May 6, 2022, at 05:07, Miro Hrončok wrote: I haven't tested the fancy new `-w` option, but the macros work fine on my existing RPM builds in mock on rawhide/f36. 🎉 -- Major Hayden

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/RE... > [4] > https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=py... > [5] Fedora Python SIG <python-devel(a)lists.fedoraproject.org&gt; > > > Happy packaging,