Hey,
On Mon, May 15, 2023, 22:04 Dan Čermák <dan.cermak@xxxxxxxxxxxxxxxxxx> wrote:
Hi Igor,
On May 15, 2023 6:24:07 PM UTC, Igor Raits <igor.raits@xxxxxxxxx> wrote:
>On Thu, Mar 30, 2023 at 11:56 PM Miro Hrončok <mhroncok@xxxxxxxxxx> 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.
I think brp script runs exactly before subpackages are created.
>>
>> %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@xxxxxxxxxxxxxxxxxxxxxxx
>> To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx
>> 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@xxxxxxxxxxxxxxxxxxxxxxx
>> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
>
>
>
_______________________________________________ packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
