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
--
_______________________________________________
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
