When reviewing https://src.fedoraproject.org/rpms/pyproject-rpm-macros/pull-request/291
we have discovered that there is no macronized way to get this part of some paths
and that packagers need to hardcode it as cpython-%{python3_version_nodots}.
This way, we have a standardized macro packagers (and other macros) can use.
Implemented in: https://github.com/python/cpython/pull/27926
We keep using it thou, because this is Python version agnostic.
Once we drop support for anything older than 3.11, we can remove it.
That'll be around ~2030. Assuming the world still exists by then.
In Koji, python3-rpm-generators are not installed during the build.
However, packagers can have them installed locally, in mock or in Copr.
This way, we make sure the automatic provides (and obsoletes)
do not magically appear only in some environments.
Since python3-rpm-macros actually requires python-rpm-macros,
the requirement is self-satisfied when the automatic provides are generated.
I.e. when %python3_pkgversion is 3.12, %__python3 is /usr/bin/python3.12
We assume that when packagers pacakge for Python 3.X, they want to change both
%python3_pkgversion and %__python3 value.
Hence instead of copy-pasting this:
%global python3_pkgversion 3.X
%global __python3 /usr/bin/python3.X
They just need to do:
%global python3_pkgversion 3.X
Packagers who want to change the value of %__python3 without touching
%python3_pkgversion can still do it:
%global __python3 /usr/bin/pypy3
Related to https://bugzilla.redhat.com/1821489
%%py{3}_check_import now respects the custom setting of %%py{3}_shebang_flags
and invokes Python with the respective values.
If %%py{3}_shebang_flags is undefined or set to no value,
there no flags are passed to Python on invoke.
Resolves: rhbz#2018615
-f: optionally read a file with module names to test
-t: bool flag - if set, filter only top-level modules
-e: optionally exclude module names matching the given glob (Unix
shell-style wildcards)
Importing all modules may cause bogus failures in some cases,
eg. when the imported code assumes there is an existing graphical window.
Such behaviour may be by design, hence for automatic processing it's
more convinient to - in some cases - check only for top-level modules
or filter out the troublemakers.
Our Pythons currently patches distutils to install packages to
/usr/lib(64)/pythonX.Y/site-packages when the $RPM_BUILD_ROOT environment
variable is set (and to /usr/local/lib(64)/pythonX.Y/site-packages otherwise).
With the deprecation of distutils [1] we want to change the patch to create
and use a different sysconfig install scheme [2].
However, we have realized that macros defined as %(%{__python3} ...) don't
"see" the environment variables set by rpmbuild because they are expanded earlier
and hence e.g. %{python3_sitelib} evaluates to
/usr/local/lib/python3.X/site-packages -- which is not desired.
To be able to reliably detect an RPM build environment by checking
the presence of the $RPM_BUILD_ROOT environment variable,
we manually set it in the macro definitions.
Since %{buildroot} in not fully populated
(e.g. it can expand literally to
/home/anna/rpmbuild/BUILDROOT/%{NAME}-%{VERSION}-%{RELEASE}.x86_64),
we don't use it here.
The variable simply needs to present in the environment.
See also the analysis of the build failures when this is not done [3].
[1] https://www.python.org/dev/peps/pep-0632/
[2] https://bugs.python.org/issue43976
[3] https://src.fedoraproject.org/rpms/python3.10/pull-request/63#comment-79042
- For depth, use sys.getrecursionlimit()
- the default from bytecompile2
- we'll get a RecursionError before it's exceeded, anyway
- Set real_libdir locally
This allows us to maintain our own BuildRoot Policy scripts in an easier way.
This change needs to be coordinated with the removal of the files from redhat-rpm-config.
redhat-rpm-config requires python-srpm-macros, so no change is expected for the packagers.
With $PATH and $PYTHONPATH set to the %buildroot,
the macro tries to import the given Python 3 module(s).
Useful as a smoke test in %check when ruining tests is not feasible.
Accepts spaces or commas as separators.
Package python-six:
%check
%py3_check_import six
Executing(%check): ...
...
+ PATH=...
+ PYTHONPATH=...
+ PYTHONDONTWRITEBYTECODE=1
+ /usr/bin/python3 -c 'import six'
+ RPM_EC=0
++ jobs -p
+ exit 0
%py3_check_import six seven
...
+ /usr/bin/python3 -c 'import six, seven'
Traceback (most recent call last):
File "<string>", line 1, in <module>
ModuleNotFoundError: No module named 'seven'
error: Bad exit status from ... (%check)
...
%py3_check_import five, six, seven
+ /usr/bin/python3 -c 'import five, six, seven'
Traceback (most recent call last):
File "<string>", line 1, in <module>
ModuleNotFoundError: No module named 'five'
error: Bad exit status from ... (%check)
Package python-packaging:
%py3_check_import packaging, packaging.markers packaging.requirements, packaging.tags
Executing(%check): ...
...
+ PATH=...
+ PYTHONPATH=...
+ PYTHONDONTWRITEBYTECODE=1
+ /usr/bin/python3 -c 'import packaging, packaging.markers, packaging.requirements, packaging.tags'
+ RPM_EC=0
++ jobs -p
+ exit 0
%py3_check_import packaging, packaging.markers packaging.notachance, packaging.tags
...
+ /usr/bin/python3 -c 'import packaging, packaging.markers, packaging.notachance, packaging.tags'
Traceback (most recent call last):
File "<string>", line 1, in <module>
ModuleNotFoundError: No module named 'packaging.notachance'
error: Bad exit status from ... (%check)
The %{? in the comment made the entire block of macros not work.
Since nobody actually used those on Fedora, because they did not exist,
we can safely remove them. No need to document this in the %changelog.
The %{?load:%{SOURCE102}} construct no longer works in RPM 4.17+
Currently, we:
1. Load %{SOURCE102} if it exists.
This should always be the case when actually building the RPM or SRPM package.
2. Else, load macros.python-srpm if it exists.
This is the case when something parses the spec from dist-git without setting
%_sourcedir to the current working directory. E.g. rpmdev-bumpspec does this.
3. Else, don't load anything, get %{__default_python3_version} from the environment.
This is the case when something parses the spec in isolation.
Getting the version from sources is impossible, because the sources are missing.
So we get the installed version instead. Note that this will blow up on Fedora < 33,
but it already did before.
Distutils which were used to define the macros are deprecated in Python3.10:
https://www.python.org/dev/peps/pep-0632/.
Sysconfig isn't and it works across our Pythons, making it better choice for the task.
This allows e.g.:
%global extras cli,ghostwriter,pytz,dateutil,lark,numpy,pandas,pytest,redis,zoneinfo,django
%{pyproject_extras_subpkg -n python3-hypothesis %{extras}}
...
%pyproject_buildrequires -x %{extras}
(Note that %pyproject_extras_subpkg is a tiny wrapper around %python_extras_subpkg.)
Avoid using the full path and instead rely on PATH being correctly set
up to find the executable.
This fixes byte compilation for python2.7 when doing flatpak module
builds where python2.7 can be in either /usr/bin or /app/bin, depending
on how it's compiled.
Fedora Release Engineering
Miro Hrončok
Tomáš Hrnčiar
Owen W. Taylor
Tomas Orsava
Charalampos Stratakis
Karolina Surma
Lumir Balhar
Petr Viktorin
Ben Burton
Kalev Lember