Hi Igor,

On May 15, 2023 6:24:07 PM UTC, Igor Raits <igor.raits@gmail.com> wrote:
>On Thu, Mar 30, 2023 at 11:56 PM Miro Hrončok <mhroncok@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@lists.fedoraproject.org
>> To unsubscribe send an email to packaging-leave@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.fedoraproject.org
>> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
>
>
>