Hi Igor,
On May 15, 2023 6:24:07 PM UTC, Igor Raits <igor.raits(a)gmail.com> wrote:
On Thu, Mar 30, 2023 at 11:56 PM Miro Hrončok
<mhroncok(a)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?
Don't the brp-scripts run after the build? I though the dynamic subpackage creation
has to occur beforehand.
>>
>> %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 -- packaging(a)lists.fedoraproject.org
>> To unsubscribe send an email to packaging-leave(a)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/packaging@lists.fedoraproje...
>> Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
>
>
>