On 30-10-2024 12:47, Miro Hrončok via python-devel wrote:
1. Allow %pyproject_save_files without arguments
%pyproject_install
%pyproject_save_files
Simple, easy. Calling %pyproject_save_files without arguments will work
and it will only save the .dist-info for %{pyproject_files}. (This will
allow to use the pyproject RPM declarative BuildSystem without
BuildOption(install) as well.)
Are there any downsides? Even if packages forget to add arguments to
%pyproject_save_files, this will work:
%install
%pyproject_install
%pyproject_save_files
%files -n python3-foo -f %{pyproject_files}
%{python3_sitelib}/foo/
My only worry now is that the "default" behavior of
%pyproject_save_files exists only to accommodate a very niche need.
I prefer the module glob being mandatory as it is now. Allowing for the
module glob to be optional suggests to me the macro will automatically
detect what it needs to save. This is not the case and it will lead to a
mix of spec file styles where some packagers will use the current syntax
with a macro populated %files section and others amending the %files
section when they actually should/could use the correct macro syntax.
2. Empty string argument
%pyproject_install
%pyproject_save_files ''
Empty argument means no modules. I don't like this, it's hard to read,
hard to explain.
Painful to read indeed. Easily overlooked, more difficult to understand.
3. Another +argument
%pyproject_install
%pyproject_save_files +nomodules
We already have +auto, so this would be another +thing. I don't like
this much, but more than 2.
I haven't had to use +auto yet. Seeing that the no modules case is
rather special as well, I could live with it being +nomodules. Though,
linguistically it's a bit weird...
4. Another short option
===
%pyproject_install
%pyproject_save_files -M
(The character choice is arbitrary.) We already have -l/-L. This would
be another such option.
I'm most in favor of this syntax. It aligns with other pyproject macros
as well as other options passed to %pyproject_save_files. It also makes
it explicit to the reader that the macro behavior is being "tweaked".
5. Do not require %pyproject_save_files in that case
%pyproject_install
This would populate %{pyproject_files} with the .dist-info only.
Subsequent %pyproject_save_files calls would override/expand it.
However, there are challenges: what happens if there are multiple wheels
installed this way? etc.
It's weird in that %{pyproject_files} is explicitly tied to the use of
%pyproject_save_files in the documentation.
-- Sandro
--
___
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, report it:
https://pagure.io/fedora-infrastructure/new_issue
