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. >> >> %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
