On Thu, Mar 30, 2023 at 11:56 PM Miro Hrončok <mhron...@redhat.com> wrote:
>
> Hello Python packagers.
>
> RPM 4.19 introduces this feature:
>
> https://rpm-software-management.github.io/rpm/manual/dynamic_specs.html
>
> I decided to write this email to gather my thoughts. I believe that with this,
> we can turn manual Python extras subpackages like this:
Is there a reason not to write a brp script so that users won't have
to do anything manually at all? Basically scan the sitelibdir for the
dist-info and create necessary parts from there?
>
> %package -n python3-...
> Summary: %{summary}
>
> %description -n python3-... %_description
>
> %pyproject_extras_subpkg -n python3-xxx extra1 extra2
>
> (See https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#Extras
> for what that means.)
>
> Into something like this:
>
> %package -n python3-...
> Summary: %{summary}
>
> %description -n python3-... %_description
> ...
>
> %install
> %pyproject_install
> ...
> %pyproject_generate_extras_subpkgs -n python3-xxx
>
>
> The %pyproject_generate_extras_subpkgs macro would parse the installed
> .dist-info directory to find out what extras are available and generate
> subpackages for all of them.
>
> (Obviously, the macro name is open up for discussion.)
>
> ----------------
>
> An API would be required to exclude extras:
>
> - that are not useful for other packages
> (for example build/development requirements, commonly named dev, doc or
> test)
> - that have requirements that are not packaged in Fedora
>
> For example (mimicking the API of %pyproject_check_import):
>
> %pyproject_generate_extras_subpkgs -n python3-xxx -e test -e 'nonfree*'
>
> ----------------
>
> However, extras are also currently manually passed to
> %pyproject_buildrequires:
>
> %generate_buildrequires
> %pyproject_buildrequires -x extra1 -x extra2 -x test
>
> It should already be possible to implement automatic extras discovery in
> %pyproject_buildrequires with older RPM versions and allow it to be used this
> way:
>
> %generate_buildrequires
> %pyproject_buildrequires <FLAG_TO_ENABLE_ALL_EXTRAS> -X 'nonfree*'
>
> RPM macros can only accept short flags, so <FLAG_TO_ENABLE_ALL_EXTRAS> can
> either be -x '*' (if we start treating -x values as globs, which is backwards
> compatible and probably generally useful), or a single-letter switch such as
> -a
> (but honestly we are running out of meaningful letters).
>
> (When -X is used, <FLAG_TO_ENABLE_ALL_EXTRAS> can probably be implied.
> However,
> an explicit form needs to exist for packages that don't need to exclude any
> extras at all.)
>
>
> Eventually, I'd like to make <FLAG_TO_ENABLE_ALL_EXTRAS> the default, once RPM
> 4.19 is omnipresent.
>
> ----------------
>
> Combined, this would mean that the packager needs to:
>
> 1. specify extras that are not supposed to be used as BRs
> 2. specify extras that are not supposed to be packaged
>
> In the ideal word (2) is a superset of (1).
>
> Should %pyproject_generate_extras_subpkgs somehow inherit the -Xes from
> %pyproject_buildrequires?
>
> When a package has extra1, extra2, nonfree1, nonfree2 and test extras, one
> could do:
>
> %generate_buildrequires
> %pyproject_buildrequires <FLAG_TO_ENABLE_ALL_EXTRAS> -X 'nonfree*'
>
> ...
>
> %pyproject_install
> ...
> %pyproject_generate_extras_subpkgs -X test
>
> That would mean:
>
> - extra1 is BRed and packaged
> - extra2 is BRed and packaged
> - test is BRed but not packaged
> - nonfree1 is neither
> - nonfree2 is neither
>
> ----------------
>
> Alternatively the information could be supplied by %globals:
>
> %global _python_ignored_extras nonfree*
> %global _python_unpackaged_extras test
>
> However, I somehow dislike this approach.
>
> ----------------
>
> I'd appreciate your thoughts on the matter.
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> _______________________________________________
> packaging mailing list -- packag...@lists.fedoraproject.org
> To unsubscribe send an email to packaging-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/packag...@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
--
— Igor Raits.
_______________________________________________
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
