It definitely feels like the current macros didn't take into account
these scenarios from the usability standpoint, which appears to be
common. It requires the maintainer to workaround the detection logic and
write counter intuitive code. Right now it is setup.py.in, but
eventually could be pyproject.toml.in.
Is there a way to tell it to run the logic for setup.py or for
pyproject.toml without actually looking for the existence of the file?
Would it be possible to add that feature if not? That way I could just
indicate with the macro alone the kind of project it is.
Regards,
Carlos R.F.
On 8/19/25 8:09 AM, Miro Hrončok wrote:
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.
Either use setup.py.in as a stub or in the worst situation, use:
%generate_buildrequires
%pyproject_buildrequires -N
The two packages I have attempted to migrate are libdnet[1] and
strongswan[2]
[1] https://src.fedoraproject.org/rpms/libdnet
[2] https://src.fedoraproject.org/rpms/strongswan
Here's one of them:
https://src.fedoraproject.org/rpms/strongswan/pull-request/28
Let me know if you need help with the other one.
--
_______________________________________________
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
