Miro Hrončok venit, vidit, dixit 2025-08-19 17:09:13: > On 19. 08. 25 16:33, Carlos Rodriguez-Fernandez wrote: > > So, basically, don't use the following macros but write the BuildRequires? > > > > %generate_buildrequires > > %pyproject_buildrequires > > No, you MUST use them. But ideally use them after *some* setup.py is > generated.
Well, it's easy to declare something as MUST, but really those macros cannot be incorporated as part of some typical upstream build setups, simply because they are no *commands* which you call (instead of an upstream command). Not all packages involving python are python only. Imagine a package which upstream builds like this: - configure writes, among other things, version info - make does - among other things - the following: - - build a library - - call setup.py to build the python part (which depends on the lib) - - use sphinx autodoc on the built python modukes Now the pyproject macros come along: - pyproject_buildrequires needs to be done before "%build", thus before configure, but it calls setup.py for dependency info before configure can set up what setup.py needs - note that compiled features typically are determined during the configure run - autodoc needs the built py modules, but where are they when we patch out "setup.py build" and use pyproject_wheel instead? etc. Really, in all cases where I had packages like this, switching to pyproject macros meant ripping apart a perfectly fine configure/make based workflow (e.g. trimming the make all target, calling individual targets manually, doing part of configure manually), making the spec file more clumsy. Those workarounds feel like the opposite of future proofing, which the switch to te macros should be/ I don't think those more complex build setups are catered for by the macros. Alsa, remember to always do the switch to savefiles last, beacuse it's so easy to end up building less than before the switch, and savefiles hides all changes to the lest of packaged files - the opposite of what we expect packagers to do when we ask them be explicite in their files sections. Michael -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
