6210f94e46
Falling back to setuptools.build_meta:__legacy__ is the standard behavior, not setuptools.build_meta. See PEP 517: https://www.python.org/dev/peps/pep-0517/ > If the pyproject.toml file is absent, or the build-backend key is missing, > the source tree is not using this specification, and tools should revert > to the legacy behaviour of running setup.py (either directly, or by > implicitly invoking the setuptools.build_meta:__legacy__ backend). Falling back to setuptools.build_meta had very similar results so far., but the behavior might change in the feature. While working on this, I have uncovered a problem in our code. It was not able to handle backends with ":". Looking at PEP 517 again: > build-backend is a string naming a Python object that will be used to > perform the build. This is formatted following the same module:object syntax > as a setuptools entry point. For instance, if the string is "flit.api:main", > this object would be looked up by executing the equivalent of: > > import flit.api > backend = flit.api.main > > It's also legal to leave out the :object part, e.g. > > build-backend = "flit.api" > > which acts like: > > import flit.api > backend = flit.api We now handle such cases properly. Witch the change of the default backend, we also test a backend with colon in our tests. |
||
---|---|---|
tests | ||
.gitignore | ||
LICENSE | ||
macros.pyproject | ||
pyproject_buildrequires.py | ||
pyproject-rpm-macros.rpmlintrc | ||
pyproject-rpm-macros.spec | ||
README.md | ||
sources | ||
test_pyproject_buildrequires.py | ||
testcases.yaml |
pyproject RPM macros
This is a provisional implementation of pyproject RPM macros for Fedora 30+.
These macros are useful for packaging Python projects that use the PEP 517 pyproject.toml
file, which specifies the package's build dependencies (including the build system, such as setuptools, flit or poetry).
Usage
If your upstream sources include pyproject.toml
and you want to use these macros, BuildRequire them:
BuildRequires: pyproject-rpm-macros
This will bring in python3-devel, so you don't need to require python3-devel explicitly.
In order to get automatic build dependencies on Fedora 31+, run %pyproject_buildrequires
in the %generate_buildrequires
section:
%generate_buildrequires
%pyproject_buildrequires
Only build dependencies according to PEP 517 and PEP 518 will be added. All other build dependencies (such as non-Python libraries or test dependencies) still need to be specified manually.
Then, build a wheel in %build
with %pyproject_wheel
:
%build
%pyproject_wheel
And install the wheel in %install
with %pyproject_install
:
%install
%pyproject_install
%pyproject_install
installs all wheels in $PWD/pyproject-macros-wheeldir/
. If you would like to save wheels somewhere else redefine %{_pyproject_wheeldir}
.
Adding run-time and test-time dependencies
To run tests in the %check
section, the package's runtime dependencies
often need to also be included as build requirements.
If the project's build system supports the prepare-metadata-for-build-wheel
hook,
this can be done using the -r
flag:
%generate_buildrequires
%pyproject_buildrequires -r
For projects that specify test requirements using an extra
provide,
these can be added using the -x
flag.
For example, if upstream suggests installing test dependencies with
pip install mypackage[testing]
, the test deps would be generated by:
%generate_buildrequires
%pyproject_buildrequires -r -x testing
For projects that specify test requirements in their tox configuration,
these can be added using the -t
flag (default tox environment)
or the -e
flag followed by the tox environment.
The default tox environment (such as py37
assuming the Fedora's Python version is 3.7)
is available in the %{toxenv}
macro.
For example, if upstream suggests running the tests on Python 3.7 with tox -e py37
,
the test deps would be generated by:
%generate_buildrequires
%pyproject_buildrequires -t
If upstream uses a custom derived environment, such as py37-unit
, use:
%pyproject_buildrequires -e %{toxenv}-unit
Or specify more environments if needed:
%pyproject_buildrequires -e %{toxenv}-unit,%{toxenv}-integration
The -e
option redefines %{toxenv}
for further reuse.
Use %{default_toxenv}
to get the default value.
Note that -t
implies -r
, because tox normally assumes the package is installed
including all the runtime dependencies.
The -t
/-e
option uses tox-current-env's --print-deps-to-file
behind the scenes.
Running tox based tests
In case you want to run the tests as specified in tox configuration,
you can use the %tox
macro:
%check
%tox
The macro:
- Always prepends
$PATH
with%{buildroot}%{_bindir}
- If not defined, sets
$PYTHONPATH
to%{buildroot}%{python3_sitearch}:%{buildroot}%{python3_sitelib}
- If not defined, sets
$TOX_TESTENV_PASSENV
to*
- Runs
tox
with-q
(quiet),--recreate
and--current-env
(from tox-current-env) flags - Implicitly uses the tox environment name stored in
%{toxenv}
- as overridden by%pyproject_buildrequires -t
By using the -e
flag, you can use a different tox environment(s):
%check
%tox
%if %{with integration_test}
%tox -e %{default_toxenv}-integration
%endif
If you wish to provide custom tox
flags or arguments, add them after --
:
%tox -- --flag-for-tox
If you wish to pass custom posargs
to tox, use another --
:
%tox -- --flag-for-tox -- --flag-for-posargs
Or (note the two sequential --
s):
%tox -- -- --flag-for-posargs
Warning: This macro assumes you have used %pyproject_buildrequires -t
or -e
in %generate_buildrequires
. If not, you need to add:
BuildRequires: python3dist(tox-current-env)
Limitations
This macro changes shebang lines of every Python script in %{buildroot}%{_bindir}
to #! %{__python3} %{py3_shbang_opt}
(#! /usr/bin/python3 -s
).
We plan to preserve existing Python flags in shebangs, but the work is not yet finished.
Extras are currently ignored.
Some valid Python version specifiers are not supported.
The -x
flag does not yet support multiple (comma-separated) extras.