Default BuildOption(install) for the RPM pyproject declarative buildsystem - python-devel - Fedora mailing-lists

3 Jul 2024


      Hello.
I am working on the RPM pyproject declarative buildsystem.
t;dr it turns this:
BuildSystem:          pyproject
into this:
%prep
     %autosetup -p1 -C
%generate_buildrequires
     %pyproject_buildrequires
%build
     %pyproject_wheel
%install
     %pyproject_install
     %pyproject_save_files ...
%check
     %pyproject_check_import
It allows to override options to sections with BuildOption.
For detailed documentation, see 
https://src.fedoraproject.org/rpms/pyproject-rpm-macros/pull-request/455 (it 
has README changes in it).
---------------------------------
What should be the default for BuildOption(install)? That is, what should be 
passed to %pyproject_save_files if the packager does not override it?
1. The safe+hard default: nothing
=================================
The %pyproject_save_files macro currently has no default. It requires at least 
one argument. This is to avoid accidentally packaging something we don't want. 
Explicit is better than implicit.
For this reason, users of the pyproject declarative buildsystem would be 
required to always set BuildOption(install) explicitly.
Why I don't like this option: The declarative buildsystem was invented to make 
spec files simpler. Making BuildOption(install) mandatory defeats the purpose.
2. The easy+dangerous default: '*'
==================================
When we pass '*' to %pyproject_save_files by default, we ensure all packages 
work without BuildOption(install). This is the easy way. Everything is 
automagic, no boilerplate necessary.
Passing '*' to %pyproject_save_files is forbidden by the Fedora packaging 
guidelines because it is dangerous. If upstream removes a Python module or 
(perhaps accidentally) adds a new one that conflicts with other packages, the 
Fedora packager should notice.
Why I don't like this option: The default is forbidden in Fedora and hence it 
is only useful elsewhere (e.g. Copr). Defaults should encourage the desired 
pattern, defaults should not be forbidden. Packagers will use the default and 
the rule will be ignored as not practical.
3. Guess the module name: python-foo -> foo
===========================================
When the package is named somehow, we like the Python modules to be named 
identical-ish. We can create a transformation of %{name} and make that the 
default. Something like this:
1. Strip python- prefix if found.
  2. Strip everything after a dot (including the dot) if found.
  3. Convert dashes, dots etc. to underscores.
Some nice examples:
python-requests -> requests
python-zope.interface -> zope
python-flit-core -> flit_core
tomcli -> tomcli
Examples that would need manual BuildOption(install):
python-zope-interface -> zope_interface (we need zope)
python-djangorestframework -> djangorestframework (we need rest_framework)
pytest -> pytest (we need pytest _pytest py)
This would produce a reasonable default that is easy and safe for sane packages 
but it is not dangerous for the weird ones.
Option 3a) is to do this in the pyproject declarative buildsytsem macros 
implementation. Explicit callers of %pyproject_save_files would not be able to 
use this, which only has downsides.
Option 3b) is to make this the behavior of %pyproject_save_files when it has no 
arguments. If additional module globs are necessary, all module globs need to 
be passed explicitly.
Option 3c) is to make this the behavior of `%pyproject_save_files -n` and make 
-n the default BuildOption(install). Users of %pyproject_save_files could 
combine -n with explicit module glob list (e.g. `%pyproject_save_files -n 
_pytest py` for pytest).
Why I don't like this: Its' heuristics. It smells like guesswork. I prefer 
things explicit.
4. Default to %{pypi_name}
==========================
Similarly to option 3, we prefer the PyPI name and the module name to match.
Hence, we could default to %{pypi_name} or %{srcname} like %{pypi_source} does.
There would still need to be some transformations applied, because %{pypi_name} 
can contain dashes and dots, etc...
Why I don't like this: %{pypi_name} is not a cardinal part of a package. It's 
not part of the Python packaging guidelines and does not have a clearly defined 
semantics (is it the project name or the name part of the source tarball?). It 
encourages packagers to define the macro and use it everywhere in the spec, 
making it harder to read. Moreover, we need to apply text transformations to it 
anyway, hence we might as well do them on %{name} directly (which does not have 
clear semantics either, but is always there).
---------------------------------
If I had to pick, I'd go with 3c. IMHO it is the most sane option.
What are your thoughts? Do you see other options?
-- 
Miro Hrončok
-- 
Phone: +420777974800
Fedora Matrix: mhroncok