This package is already installed -- otherwise the macro would not even exist.
However, since python3-devel has started to Require pyproject-rpm-macros,
it is no longer possible to use `repoquery --whatrequires pyproject-rpm-macros`
to get a reliable list of packages that use the macros.
This was, all packages that use %pyproject_buildrequires will BuildRequire the macros explicitly.
(In the future, we could even include a stub version of %pyproject_buildrequires
in pyproject-srpm-macros (always installed in the buildroot),
that only echoes this package,
so packagers would not need to manually BuildRequire anything at all.)
Compressed manpages have different extension than those listed in the RECORD file,
so they were not recognized when %%pyproject_save_files '+auto' flag
was provided.
To enable the path recognition, if the manpage extension matches the one
listed in brp-compres, the extension is removed, and an asterisk is now added
to the manpages filenames.
Source: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_manpages
Fixes: https://bugzilla.redhat.com/2033254
`python3-devel` already requires `pyproject-rpm-macros` in Fedora and
EPEL 9. Update the usage docs to reflect this.
Signed-off-by: Hunor Csomortáni <csomh@redhat.com>
Improve handling of > operator, preventing post-release from satisfying most rpm requirements.
Improve handling of < operator, preventing pre-release from satisfying rpm requirement.
Improve handling of != operator with prefix matching, preventing pre-release from satisfying rpm requirements.
%%pyproject_save_files newly saves also a list of importable modules.
The list is used by %%pyproject_check_import to invoke the import test
on each module name.
%%pyproject_check_import accepts two options:
-t: filter only top-level modules
-e: exclude module names matching the given glob from the import check
%pyproject_buildrequires macro now accepts multiple file names to load
additional dependencies from them.
New option -N was added to disable automatical generation of requirements
in case package does not use build system. Option -N cannot be used in
combination with options -r, -e, -t, -x.
Co-authored-by: Miro Hrončok <miro@hroncok.cz>
This allows users to do:
%build
cd somewhere
%pyproject_wheel
cd -
cd somewhere_else
%pyproject_wheel
cd -
%install
%pyproject_install
Without a need to copy paste the wheels to a common location.
This is in fact a breaking change, I'll make sure to adapt the affected packages in Fedora.
The macro already checks if pyproject.toml exists and echoes the dependency
on python3dist(toml) early. This adds an else branch to echo the default backend.
For projects without pyproject.toml, the number of installation rounds
is reduced. Previously:
1. (python3-devel +) pip + packaging
2. setuptools + wheel
3. ...
Now:
1. (python3-devel +) pip + packaging + setuptools + wheel
2. ...
This duplicates the information about the default build backend,
because the script still needs to handle projects with pyproject.toml without
an explicit build backend option.
Hence, the script was not adapted (except a comment).
The macro checks if pyproject.toml exists and echoes the dependency early.
For projects with pyproject.toml, this saves one installation round.
Previously, the installation steps by %generate_buildrequires were:
1. (python3-devel +) pip + packaging
2. toml
3. parsed dependencies from pyproject.toml
4. ...
Now they are:
1. (python3-devel +) pip + packaging + toml
2. parsed dependencies from pyproject.toml
3. ...
For projects without pyproject.toml, the number of rounds remains the same:
1. (python3-devel +) pip + packaging
2. setuptools + wheel
3. ...
This is also more consistent:
The Python script now only outputs dependencies of the probed project,
it no longer partially outputs dependencies for itself.
