Hey,
On Mon, May 15, 2023, 22:04 Dan Čermák dan.cermak@cgc-instruments.de wrote:
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.
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:
- specify extras that are not supposed to be used as BRs
- 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....
Do not reply to spam, report it:
python-devel@lists.fedoraproject.org