These macros allow projects that follow the Python packaging specifications to be packaged as RPMs. They work for: * traditional Setuptools-based projects that use the setup.py file, * newer Setuptools-based projects that have a setup.cfg file, * general Python projects that use the PEP 517 pyproject.toml file (which allows using any build system, such as setuptools, flit or poetry). These macros replace %%py3_build and %%py3_install, which only work with setup.py.
Go to file
Miro Hrončok 6210f94e46 Handle backends with colon, fallback to setuptools.build_meta:__legacy__
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.
2020-02-05 13:31:45 +01:00
tests Tests: Simplify tldr.spec 2019-11-22 13:56:05 +01:00
.gitignore Refactor and add tests 2019-07-17 15:57:02 +02:00
LICENSE initial import (#1717389) 2019-07-02 12:41:04 +02:00
macros.pyproject create directory in $PWD for built wheel 2019-11-21 13:12:18 +01:00
pyproject_buildrequires.py Handle backends with colon, fallback to setuptools.build_meta:__legacy__ 2020-02-05 13:31:45 +01:00
pyproject-rpm-macros.rpmlintrc Add rpmlint RC file and URL 2019-07-02 13:06:11 +02:00
pyproject-rpm-macros.spec Handle backends with colon, fallback to setuptools.build_meta:__legacy__ 2020-02-05 13:31:45 +01:00
README.md create directory in $PWD for built wheel 2019-11-21 13:12:18 +01:00
sources initial import (#1717389) 2019-07-02 12:41:04 +02:00
test_pyproject_buildrequires.py Use importlib_metadata rather than pip freeze 2019-09-18 16:16:17 +02:00
testcases.yaml Use importlib_metadata rather than pip freeze 2019-09-18 16:16:17 +02:00

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.