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.)
Since Fedora 33, the package version always == %{__default_python3_version}.
When we update Python to 3.X+1, we update the version and the macro.
When the macro is not updated confusing things happen.
See for example https://bugzilla.redhat.com/show_bug.cgi?id=1931421#c4
We could assert the versions match in %check instead,
but this way a temporary pull request for a new Python version, such as
https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/50https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/84
can be kept rebased via the git forge UI.
Note that the value of %{__default_python3_version} is loaded from sources in
dist git, otherwise it would be defined by the previous build of this package.
As a result, the spec file is no longer parsable on it's own, but IMHO that's OK.
https://fedoraproject.org/wiki/Changes/Disable_Python_2_Dist_RPM_Generators_and_Freeze_Python_2_Macros
This is to be shipped together with an upgrade of python2.7:
The python2.7 RPM package will contain the removed macros instead.
The release is intentionally over-bumped to allow some changes of
python-rpm-macros in lower versions of Fedora without the need to bump
the version-release of python2-rpm-macros obsoleted by python2.7.
This only works for package and extra names less than 79 characters long.
I don't expect many actual packages to exceed this limit.
78 characters should be enough for everybody.
Why 78? 79 is the line-lenght limit from rpmlint.
And we need to put punctuation in there.
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.
By default, %{py3_dist foo} generates python3dist(foo).
This change makes it respect %python3_pkgversion so when
it is redefined as X.Y, %{py3_dist foo} generates pythonX.Y(foo).
--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.
Previous implementation allowed for only one argument to be passed to
the %pycached macro, which made it impossible to combine it with other macros.
Current implementation allows to pass other macros as arguments to
%pycached.
Example:
%pycached %exclude /path/to/foo.py
For macro expansion limitations, the opposite order is not possible.
That is to be documented in the guidelines:
https://pagure.io/packaging-committee/pull-request/986
Added some tests.
Resolves https://bugzilla.redhat.com/show_bug.cgi?id=1838992
Co-authored-by: Marcel Plch <mplch@redhat.com>
To avoid mock using a local copy of python-srpm-macros from the buildroot cache
and having Python version defined to 3.8 until the cache expires.
Also, other surprises happened in the past, so we stop playing it cool and
actually follow the guidelines here.
%pyhon_provide in python-rpm-macros uses new Lua functions from python-srpm-macros
People have python-srpm-macros pre-installed, and it is not autoupdated,
hence they can have older versions installed and it blows up.
- 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.
Usage:
%files
...
%pycached %{python3_sitelib}/foo.py
This will list:
/usr/lib/python3.8/site-packages/foo.py
/usr/lib/python3.8/site-packages/__pycache__/foo.cpython-38{,.opt-?}.pyc
Assuming the Python 3 version is 3.8.
The bytecode files are globbed, their presence is not checked.
This will fail:
%pycached %{python3_sitelib}/foo
error: %pycached can only be used with paths explicitly ending with .py
And so will any of this:
%pycached %{python3_sitelib}/*
%pycached %{python3_sitelib}/foo.*
%pycached %{python3_sitelib}/foo.p?
%pycached %{python3_sitelib}/foo.?y
%pycached %{python3_sitelib}/foo.??
But this will work:
%pycached %{python3_sitelib}/foo*.py
And it will generate the following globs:
/usr/lib/python3.8/site-packages/foo*.py
/usr/lib/python3.8/site-packages/__pycache__/foo*.cpython-38{,.opt-?}.pyc
When used with paths that include Python 3 version, it globs with the version:
%pycached /opt/python3.10/foo.py
Generates:
/opt/python3.10/foo.py
/opt/python3.10/__pycache__/foo.cpython-310{,.opt-?}.pyc
While paths without version have less strict globs:
%pycached /custom/foo.py
/custom/foo.py
/custom/__pycache__/foo.cpython-3*{,.opt-?}.pyc
This will generate a warning in RPM build:
warning: File listed twice: /custom/__pycache__/foo.cpython-38.opt-1.pyc
However it ensures the optimized bytecode is there.
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/
