Hey, On Mon, May 15, 2023, 22:04 Dan Čermák <dan.cer...@cgc-instruments.de> wrote:
> Hi Igor, > > On May 15, 2023 6:24:07 PM UTC, Igor Raits <igor.ra...@gmail.com> wrote: > >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? > > 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 -- 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 > > > > > > >
_______________________________________________ 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
