This adds a new flag, -p, to %pyproject_buildrequires.
When set, the runtime dependencies are read from the pyproject.toml's
[project] table.
See: https://bugzilla.redhat.com/2261939
pyproject_buildrequires.py already had a short `-p` option for
--python3_pkgversion (hidden from the macro users).
This change removes the one-letter option and leaves the long-one.
`-p` is now reused for reading dependencies from pyproject.toml
and made visible to the macro users.
(cherry picked from commit 9f43e2a760)
- The -l flag can be used to assert at least 1 License-File was detected
- The -L flag explicitly disables this check (which remains the default)
Co-Authored-By: Maxwell G <maxwell@gtmx.me>
I have seen several folks building this package in a RHEL 8 environment.
This won't prevent them doing so, but at least they will be forced to make changes,
acknowledging the fact that what they are doing has consequences.
Macro which allows to pass the import check even if no Python modules
are detected in the package.
Only to be used in the automated environments.
Co-authored-by: Miro Hrončok <miro@hroncok.cz>
RPM 4.19 now requires 2 %s to escape a single literal % in the filelist.
The test has been adjusted to actually run our code
instead of only verifying the assumptions.
Related: rhbz#2208971
python3-devel is not installed, hence the conditional needs to be on python3.
It only "worked" with toml because toml was pulled as a transitive dependency.
Related: rhbz#2208971
Dependencies are recorded to a text file that is catted at the end.
This should prevent subtle bugs like https://bugzilla.redhat.com/2183519 in the future.
Related: rhbz#2208971
An incomplete .dist-info directory in $PWD can confuse tests in %check.
For example, virtualenv uses importlib.metadata to load its
entry points and it does not work when it finds a virtualenv...dist-info without them.
Related: rhbz#2208971
When the build backend prints to stdout via non-Python means,
for example when a setup.py script calls a verbose program via os.system(),
the output leaked to stdout of %pyproject_buildrequires was treated as generated BuildRequires.
Fore example, if the setup.py script has:
rv = os.system('/usr/bin/patch -N -p3 -d build/lib < lib/py-lmdb/env-copy-txn.patch')
(From https://github.com/jnwatson/py-lmdb/blob/py-lmdb_1.0.0/setup.py#L117)
The stdout of /usr/bin/patch leaked to stdout of %pyproject_buildrequires:
[lmdb-1.0.0]$ /usr/bin/python3 -Bs /usr/lib/rpm/redhat/pyproject_buildrequires.py --python3_pkgversion 3 2>/dev/null
python3dist(setuptools) >= 40.8
python3dist(wheel)
patching file lmdb.h
patching file mdb.c
python3dist(wheel)
patching file lmdb.h
patching file mdb.c
This resulted in DNF errors like this:
No matching package to install: 'lmdb.h'
No matching package to install: 'mdb.c'
No matching package to install: 'patching'
Moreover, it resulted in bogus BuildRequires that may have existed (e.g. "file").
By replacing the usage of contextlib.redirect_stdout
(which only redirects Python's sys.stdout)
with a custom context manager that captures stdout on file descriptor level
(in addition to Python's sys.stdout),
we avoid this leak.
File descriptor magic heavily inspired by the capfd pytest fixture.
Related: rhbz#2168193
pyproject-srpm-macros is intended to be installed in the default buildroot.
That way, no explicit BuildRequires for pyproject-rpm-macros are required,
as long as %pyproject_buildrequires is used in %generate_buildrequires.
When only pyproject-srpm-macros is installed, the minimal implementation of
%pyproject_buildrequires generates a dependency on pyproject-rpm-macros.
When pyproject-rpm-macros is installed, it overrides the implementation
of %pyproject_buildrequires with the full one.
Note that in Fedora, pyproject-rpm-macros is required by python3-devel,
but not in RHEL.
This allows us to keep pyproject-rpm-macros in the RHEL CRB repository.
Related: rhbz#2168193
The new %py3_test_envvars macro was added
to remove duplication of environment variables used in %check.
We reuse it in %tox to gain support e.g. for PYTEST_XDIST_AUTO_NUM_WORKERS.
However, we keep support for platforms where the macro is not yet available,
not to be forced to backport %py3_test_envvars everywhere right away.
Technically, this should change little, but it sets CFLAGS and LDFLAGS now,
hence a new Y version.
Related: rhbz#2168193
When certain modules are deliberately not included into the built RPM,
they shouldn't be listed in the list of qualified module names which are
used by %pyproject_check_import to test importability of the
distribution.
Related: rhbz#2168193
Files still need to be marked as License-File to be considered %license,
but if their path in METADATA is specified relative to dist-info/licenses,
they are correctly recognised.
This makes License-Files specified by hatchling 1.9.0+ marked as %license.
Related: rhbz#2168193
Users invoking %pyproject_save_files with glob: '*' don't care about the
files in the Python package, hence it shouldn't error when no modules
are detected.
There may be legitimate reasons to create a package without Python
modules in it, hence we shouldn't be blocking this possibility.
Related: rhbz#2117571
When extension modules are built in %pyproject_buildrequires,
we need to create the package note file.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=2097535
This is tested via python-ldap -- %pyproject_buildrequires -w fails without the fix.
Neither python-markupsafe nor python-mistune can be used as a test
because they only warn when the extension module cannot be built
because they fallback to pure Python.
Related: rhbz#2117571
