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? -- 真実はいつも一つ！/ Always, there's only one truth! -- _______________________________________________ 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
