%%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.
Previously, we have used `grep -v` to assert something is *not* there.
However, that doesn't work. See for example this file:
$ cat TEST
line1
line2
line3
$ grep -v line4 TEST
line1
line2
line3
$ echo $?
0
This gives a false sense of correctness, however it exits will 0 with anything:
$ grep -v line3 TEST
line1
line2
$ echo $?
0
Instead, we use `! grep` now:
$ ! grep line4 TEST
$ echo $?
0
$ ! grep line3 TEST
line3
$ echo $?
1
Additionally, remove a trailing slash from one of the checks to match both cases
(with or without the slash).
The PEP 517 shows an example backend-path like this:
[build-system]
# Defined by PEP 518:
requires = ["flit"]
# Defined by this PEP:
build-backend = "local_backend"
backend-path = ["backend"]
https://www.python.org/dev/peps/pep-0517/#source-trees
See that backend-path is a list. Our code previously only supported string path.
Obviously a string path is wrong, but we keep it to support projects that have
made the mistake, such as flit-core.
Add a small integration test for both cases.
Note that the new spec files deliberately don't do much, to save CI time.
There is a slight problem when reporting that a dependency with extra is satisfied.
In fact, we only check the "base" dependency.
This can lead to a problem when a dependency is wrongly assumed as present
and the script proceeds to the "next stage" without restarting --
if the next stage tries to use (import) the missing dependency,
the script would crash.
However, that might be a very unlikely set of events and if such case ever happens,
we'll workaround it or fix it.
With changes in PEP 610 there is new file direct_url.json created, since it is not useful
for us we prevent it's creation. This commit changes %pyproject_install macro to install wheel using
name instead of path.
This commit also includes new test to check if file direct_url.json wasn't created.
https://discuss.python.org/t/pep-610-usage-guidelines-for-linux-distributions/4012
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>
