pyproject-rpm-macros 1.2.0: Improved support for alternate build
backends (e.g. hatchling)
by Miro Hrončok
Hello Pythonistas.
I am glad to announce the release of pyproject-rpm-macros 1.2.0.
The new version is available in rawhide and waits for your karma in
updates-testing for older Fedoras:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-80586f3147
https://bodhi.fedoraproject.org/updates/FEDORA-2022-d4047b4440
https://bodhi.fedoraproject.org/updates/FEDORA-2022-64c16b2d38
Update for c9s will follow shortly.
What's new since 1.0.0
======================
Version 1.1.0 introduced support for nested directories in the *.dist-info
metadata directory. This was not needed before, as there was no known build
backend creating such directories. However, hatchling [1] does that and more
and more packages in Fedora are using it. This is a backward-compatible change
and you should not need to change anything unless you listed files in nested
directories manually -- this workaround can now be removed. The removal is
optional: if not removed RPM will only warn about files listed twice.
More importantly, version 1.2.0 added support for reading runtime dependencies
via %pyproject_buildrequires for build backends not supporting the PEP 517
prepare_metadata_for_build_wheel [2] (such as hatchling as well). Until now,
when you wanted to get the runtime dependencies (%pyproject_buildrequires -r:
the default) or use other functionality depending on it
(%pyproject_buildrequires -x/-t/-e) and the backend did not support it, it
failed -- you had to disable it by using -R.
However, PEP 517 explicitly says:
"""
If a build frontend needs this information and the method is not defined, it
should call build_wheel and look at the resulting metadata directly.
"""
%pyproject_buildrequires now provisionally support exactly that with the new -w
flag. When -w is used, the wheel is built and the macro looks at the resulting
metadata directly. Read all about it in the README [3] in the "Adding run-time
and test-time dependencies" section. A short tl;dr here:
- due to technical limitations, the wheel is built twice
- you can omit %build/%pyproject_wheel to avoid building it for the 3rd time
- don't patch/sed between %pyproject_buildrequires -w and %pyproject_wheel
- the -w flag builds the wheel even when the hook exists
As this is a provisional functionality, the API and/or behavior might change in
the future. Hence it is not yet mentioned in the packaging guidelines. You are
allowed to use it if you are prepared for potential breakage in the future.
Where to get help
=================
Report bugzillas [4] or write to this list [5] if you encounter any problems or
if you need help.
[1] https://pypi.org/project/hatchling/
[2] https://peps.python.org/pep-0517/#prepare-metadata-for-build-wheel
[3]
https://src.fedoraproject.org/rpms/pyproject-rpm-macros/blob/rawhide/f/RE...
[4]
https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=pyproj...
[5] Fedora Python SIG <python-devel(a)lists.fedoraproject.org>
Happy packaging,
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
1 week, 4 days
- 3
- 3
Splitting alternative Python packages into subpackages, e.g.
python3.11{,libs,devel,...}
by Tomáš Orsava
Hi Python-devel,
we are considering splitting the alternative Python versions from a
single-package format (e.g. python3.11) to multiple subpackages (e.g.
python3.11{,-libs,-devel,-tkinter,-test,-idle}). We do this already with
the main `python3` package: it requires less disk space to install and
speeds up download times, because you can chose which bits are important
to you. For example, if you decide you don't need python3-tkinter, you
save yourself ~18 dependent packages leading to a total savings of
~20MBs, while skipping python3-test saves you further ~10MBs.
What do you think?
The push came from [BZ#2063227] where the reporters would welcome to
have a smaller python3.11 package for containers and VMs for local
testing, CI purposes and more.
This would be a larger amount of work, so our initial reaction was
hesitant. We'll have to change the already complicated spec file %bcond
logic, and adjust the ecosystem to work with the new subpackages. For
example tox would need to Recommend `python3.11-devel`, as `python3.11`
would bring in only the bare interpreter. And of course a thorough
integration testing would be in order.
However, we already do separate subpackages for alternative stacks in
Enterprise Linux (CentOS /Stream, RHEL, EPEL) and as a general rule we
consider it good to have fewer differences between Fedora and EL. This
helps to test things earlier, and there are fewer surprises in user
experience. So perhaps the effort in doing this would be well spent.
To cut down on the amount of work, we're considering changing only the
`python3.11` package (and any future newer versions) right now. If later
we consider it worth it, we could switch the older alternative
interpreters as well, or we might let them die out as they are.
We're currently in the brainstorming stage, so you're feedback is welcome.
[BZ#2063227] https://bugzilla.redhat.com/show_bug.cgi?id=2063227
All the best,
Tomáš
1 week, 5 days
- 4
- 5
- ← Newer
- 1
- Older →