-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
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)
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.
Versioned pathfixX.Y.py is available in main as well as in
alternative Pythons so this change enables to build
an alternative Python stack without a dependency on the main
python3-devel.
--no-index saves a ~1 minute timeout of pip possibly checking if there is
a newer pip version (in mock with disabled network).
--no-warn-script-location removes a bogus warning that says:
WARNING: The scripts easy_install and easy_install-3.9 are installed in
'/builddir/build/BUILDROOT/python-setuptools-49.2.0-1.fc33.x86_64/usr/bin'
which is not on PATH.
Consider adding this directory to PATH or, if you prefer to suppress this warning,
use --no-warn-script-location.
See https://fedoraproject.org/wiki/Changes/PythonMacroError
While doing it, make %python macros more consistent with %python3 macros,
mostly wrt whitespace but also to use python -m pip over plain pip etc.
One significant change is the removal of sleeps from python macros,
this could affect packages that use python macros to build for Python 2
while also using python3 macros to build for Python 3.
In reality, I consider that unlikely. The sleep in python2 macros stays.
The --strip-file-prefix option was already removed from %pyX_install_wheel
but we forgot to remove it from %py_install_wheel.
- Hardcode the default Python 3 version in the SRPM macros
- Provide python38-foo for python3-foo and the other way around (future RHEL compatibility)
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1812087
$ rpm --eval '%python_provide python38-setuptools'
Provides: python-setuptools = %{version}-%{release}
Provides: python3-setuptools = %{version}-%{release}
Obsoletes: python-setuptools < %{version}-%{release}
$ rpm --eval '%python_provide python3-setuptools'
Provides: python-setuptools = %{version}-%{release}
Provides: python38-setuptools = %{version}-%{release}
Obsoletes: python-setuptools < %{version}-%{release}
$ rpm --eval '%python_provide python39-setuptools'
$ rpm --define 'python3_pkgversion 39' --eval '%python_provide python%{python3_pkgversion}-setuptools'
To make the implementation of %python_provide easier,
any names starting with "python" or "pypy" are recognized as valid arguments.
Previously, this was an ERROR:
$ rpm --eval '%python_provide pythonista'
%python_provide: ERROR: pythonista not recognized.
Now it is a no-op. The behavior was never documented and the change is
backwards compatible for working spec files.
Based on recent changes in 04769fa014,
packagers might want to use:
%{?python_provide:%python_provide python2-foo%{?_isa}}
...for backwards compatibility. However the macro adds obsoletes and
since RPM 4.15, obsoletes with %{?_isa} are not possible:
Only package names are allowed in Obsoletes: Obsoletes: python-foo(x86-64) < ...
To allow such usage, %python_provide now only obsoletes if the argument
does not end with ")".
In rpm 4.15 those are no longer defined.
The meaning of "python" is derived from %__python - and that errors by default
unless user defined.
Example usage:
%global __python /usr/bin/pypy3
...
%files
%{python_sitelib}/foo/
This is needed so people can do things like:
%if %{with python3}
%global __python %__python3
%else
%global __python %__python2
%else
And than just use %__python, %py_build, %py_install,
%python_sitelib, ...
This is to ensure the right linker flags get propagated into binaries
accompanying python packages whenever distutils (or similar, env.
variables provided build flags aware) module is delegated to build them
(e.g. https://bugzilla.redhat.com/show_bug.cgi?id=1541106). Instead of
using "%{__global_ldflags}" as the seed for the respective env. variable
one-off application, which would be a direct parallel to "%{optflags}"
seeding CFLAGS, use rather "${RPM_LD_FLAGS}" and "${RPM_OPT_FLAGS}",
as these are not directly bound to macros out of rpm proper (like
it would have been, e.g., on redhat-rpm-config package otherwise).
Signed-off-by: Jan Pokorný <jpokorny@redhat.com>
