%pyproject_save_files for packages without Python modules

[Miro Hrončok]

Hello Pythonistas.

I came across a couple packages that only install .dist-info in 
%python3_sitelib/arch, or an additional .pth file.

E.g. it's a Python-packaged command line tool that installs /usr/bin/foo + 
.dist-info only (e.g. badchars, ddiskit, fuzza, isrcsubmit, ksc, pwncat, 
python-vevents, urlbuster, snallygaster). Or it installs a .pth file + 
dist-info.only (e.g. python-coverage_pth).

Currently, there is only one way to use %pyproject_save_files with them:

%pyproject_save_files '*'

THis works because a special case exists in %pyproject_save_files to support 
automated packaging e.g. in Copr. When the list of module globs contains '*', 
we assume no modules at all are OK. However, we do not allow '*' in official 
Fedora packages.

%pyproject_save_files currently requires at least one argument. So there is no 
way to call it with no globs. Currently, such packages need to manually list 
%{python3_sitelib}/xxx-%{version}.dist-info in %files. And they don't benefit 
from automatic %license discovery. I want to change that, but I want to consult 
the API ideas:

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.

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.

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.

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.

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.

-----

I'd probably go with option 1. But perhaps there's something else I have not 
figured out. Thoughts?

[Karolina Surma]

Hi,

On 10/30/24 12:47, Miro Hrončok via python-devel wrote:
I want to change
> that, but I want to consult the API ideas:
> 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'm not the biggest fan of this option. Exactly for the reason you 
described: it looks clear and tempting and I suspect this could become a 
boilerplate which we'd see in various specfiles in time. If we don't 
mind such outcome, then I guess it's alright to make this way.
> 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.

+nomodules is verbose which is a plus. OTOH the other + option is 
explicitly forbidden in Fedora, so adding this would mean folks need to 
remember that there are some valid and some invalid arguments. Because 
of that overhead I'd vote against this approach.
> 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 in favour of this one. We already have a bunch of, admiteddly, 
somewhat cryptic one letter flags, e.g. in %pyproject_buildrequires, so 
this is something I'm accustomed to. The meaning of a capital letter is 
widely known. It clearly indicates the packager's intention to create 
exactly a package without modules and is visible at first glance for any 
reader of such spec (as opposed to option 1 which, for an untrained eye, 
may be easy to overlook).

[Sandro]

On 30-10-2024 12:47, Miro Hrončok via python-devel wrote:
> 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.
> 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.
> 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...
> 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".
> 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