See https://packaging.python.org/en/latest/specifications/core-metadata/#requires
That field is deprecated and should include importable module names, not distribution packages.
We have no RPM Provides for importable names.
Treating this like python3dist() Requires is wrong and may result in stuff like:
No match for argument: python3dist(pkg-resources)
For packages using python-distutils-extra.
See https://bugzilla.redhat.com/show_bug.cgi?id=2378463#c2
This bug existed from the very beginning of the %pyproject_buildrequires,
but the field is almost unused in real packages, so it was not noticed until
we asked all Python packages to be ported to the new macros.
---
I considered flattening the structure returned from requires_from_parsed_metadata_file,
but then we would need to hardcode "Requires-Dist" in various source= declarations,
so I kept the structure as is.
PEP 517 says that the argument should be named config_settings but
pip/pyproject-hooks and other build frontends just pass it as a
positional argument, so some build backends name this argument other
things. Even though those build backends are wrong, it still makes sense
to align pyproject-rpm-macros with what the other frontends do.
Ref: https://github.com/PyO3/maturin/pull/2612
Ref: https://github.com/Rogdham/pyzstd/pull/2
Since tox 4, tox does not fail without configuration
(tox.ini, or tox section in setup.cfg/pyproject.toml).
As a result, packages that use %pyproject_buildrequires with -t or -e
without having a tox confuration
only generate additional BuildRequires on tox & tox-current-env itself.
More dangerously, %tox without tox configuration does nothing (and succeeds).
This behavior is dangerous and warrants an announced breakage.
Packagers of ~100 affected Fedora packages were informed about the problem earlier in
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org/thread/ZSHSHZKVA4XJQBJD7FMMCALKN4UP5SAJ/
There will be a further announcement and warning about this change.
EPEL 9 packages are not affected,
EPEL 9 has tox 3 which fails without config by default.
The change used a newly added option for tox-current-env: --assert-config.
This was added in tox-current-env 0.0.16:
https://github.com/fedora-python/tox-current-env/pull/89
- The flag can be used to indicate no Python modules should be saved
The change wrt users using '*' was necessary,
as `glob` was undefined when `module_globs` was empty.
This way, when we add new options to the actual macro in pyproject-rpm-macros,
spec files that use them are parsable with the old pyproject-srpm-macros package.
Last time, when we added the -g option in 1.16.0,
it took at least a week for Fedora CI to be able to parse a spec file with it,
as pyproject-srpm-macros 1.16.0+ needed to actually be installed on the CI systems.
Next time this happens, the new option will be parsable with older versions of pyproject-rpm-macros
Note that the (-) syntax is not supported yet on RPM 4.16 in RHEL 9.
I'd use an expression to keep the literal set of flags for older RPM versions:
%pyproject_buildrequires(%[v"0%{?rpmversion}" >= v"4.19" ? "-" : "rRxtNwpe:g:C:"])
But macro options are not processed as macros:
https://github.com/rpm-software-management/rpm/issues/3440
As a result, this is not compatible with RHEL 9 and cannot be backported to it.
Unless the (-) syntax is backported:
https://issues.redhat.com/browse/RHEL-67161https://gitlab.com/redhat/centos-stream/rpms/rpm/-/merge_requests/60
This test was previously skipped because we didn't have new enough tox.
That's why it was never fixed for setuptools 70+.
This is a fixup for 20b7ac63f3
Keep the information about the requirement extras by storing the
Requirement instances in the list of the ignored requirements, rather
than the strings in the form they were initially read from metadata.
The requirements strings read from pyproject.toml don't contain the
extra information, we insert the extra marker only after converting them to
Requirement instances. When stored as the text, the information about
the extra went missing in the course of the script.
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.
- 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.
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.
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.
