On 24. 07. 24 6:01, Neal Gompa wrote:
On Mon, Jul 22, 2024 at 1:01 PM Miro Hrončok <mhron...@redhat.com> wrote:
On 03. 07. 24 15:00, Tomáš Orsava wrote:
On 7/3/24 12:07, Miro Hrončok wrote:
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.
I prefer option 1. This is something the users *should* actively check and
verify, so having 1 extra line for it seems reasonable to me. We're still
saving dozen+ lines of boilerplate and replacing it with one line of meaningful
input. That's much easier to use in view.
On 03. 07. 24 15:14, Petr Viktorin wrote:
> Hello,
> I recommend starting out with the explicit option. Requiring
> BuildOption(install) sounds good, and can be changed to a better default
> after people get some experience with the system.
This is now implemented in the original PR (as a fixup commit):
https://src.fedoraproject.org/rpms/pyproject-rpm-macros/pull-request/455
Could we expand on this with dynamic subpackages to support building
against multiple Python versions from a single source package and
producing flavor subpackages against each Python version enabled?
I don't have the proper energy:motivation ratio to do that at this moment. It
seems possible with nowadays RPM, but there are definitively challenges.
If I did this, I would not try to expand the declarative buildsystem, I'd try
to design this first without it and only later hook it up into that.
---
Why do you think it should be the declarative buildsystem specifically that
would benefit form this?
At the current state, it merely replaces the %prep, %generate_buildrequires,
%build, %install, and %check sections.
We could explore the possibility to use the RPM 4.19 Dynamic Spec Generation to
generate the %package and %files section from within %install or %build and
enable this in the pyproject declarative buildsystem by default. The main issue
with this approach is that the more options we need to pass to the Declarative
Buildsystem, the more incomprehensible the invocation is.
Compare:
%pyproject_save_files -l pello
...
%files -n python3-pello -f %{pyproject_files}
%doc README.md
%{_bindir}/pello_greeting
With something like this:
BuildOption(install): -l pello --doc README.md --bindir pello_greeting
Sure, the latter is shorter but also quite cryptic.
---
Anyway, as a demo, I think it should be fairly simple to generate this
automatically from package %{name}:
%package -n python3-pello
Summary: %{summary}
%description -n python3-pello
...
The biggest challenge is the value of the %description.
--
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