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>
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>
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.
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.
Resolves: https://bugzilla.redhat.com/2127958
`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>
%%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.
This is done to avoid troubles with %lang files listed as duplicated.
1. It gets rid of a warning
2. It fixes a problem described in:
http://lists.rpm.org/pipermail/rpm-list/2020-November/002041.html
This is a backwards incompatible change,
packages that rename or remove the installed files after %pyproject_install
might no longer be compatible with %pyproject_save_files.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1868346
- Explain what "provisional" means
- Say what kinds of projects the macros handle
- Tell people to BuidRequire python*-devel
- Say %pyproject_buildrequires is needed for the other macros
- Note that %pyproject_buildrequires generates `exit 11` messages
- Note that most buildsystems have prepare-metadata-for-build-wheel
This macro save generates file section to %pyproject_files. It should
simplify %files section and allow to build by some automatic machinery
Supposed use case in Fedora:
%install
%pyproject_install
%pyproject_save_files requests _requests
%files -n python3-requests -f %{pyproject_files}
%doc README.rst
%license LICENSE
Automatic build of arbitrary packages (e.g. in Copr):
%install
%pyproject_install
%pyproject_save_files * +bindir // save all modules with executables
%files -n python3-requests -f %{pyproject_files}
Co-Authored-By: Miro Hrončok <miro@hroncok.cz>
