If not checked, installing runtime requirements might fail.
When a requirement is specified in setuptools' setup_requires:
setup(
...
setup_requires=["pytest-runner"],
)
It is part of the get_requires_for_build_wheel hook output.
When runtime requirements are parsed with setuptools without all setup_requires
present, it tries to get them from the internet (at least on Fedora 33).
By checking the requirements after installing "requires_for_build_wheel",
we make sure all setup_requires are already installed.
When runtime requirements are not installed, this adds an unneeded check,
but the script would end at that point anyway, so there is no real difference.
This change introduces code from pyreq2rpm, a tested set of
requirement conversion functions used in pyp2rpm and rpm's
pythondistdeps.
This adds support for the '~=' operator and wildcards.
Pros:
- projects without pyproject.toml will have 1 less dependency
- toml will be buildable with pyproject-rpm-macros out of the box
- easier bootstrap sequence (in theory)
Cons:
- projects with pyproject.toml will have 1 more %generate_buildrequires round
In %pyproject_buildrequires, don't run python with -I but -s.
This allows projects used by the script itself, such as packaging or toml,
to be packaged using the macros, using "self" -- i.e. the code from $PWD.
%pyproject_install currently has:
`pathfix%{python3_version}.py -pni "%{__python3}" -k%{?py3_shbang_opts: -a%{py3_shbang_opts_nodash}} %{buildroot}%{_bindir}/*`
We should replace it with `%py3_shebang_fix %{buildroot}%{_bindir}/*` which expands to:
~~~~
if [ -f /usr/bin/pathfix%{python3_version}.py ]; then
pathfix=/usr/bin/pathfix%{python3_version}.py
else
# older versions of Python don't have it and must BR /usr/bin/pathfix.py from python3-devel explicitly
pathfix=/usr/bin/pathfix.py
fi
$pathfix -pni %{__python3} -k%{?py3_shebang_flags:a %py3_shebang_flags}} %{buildroot}%{_bindir}/*
~~~~
Mainly so that we:
- switch to %py3_shebang_flags
- have only one place to fix the invocation
Fixes: rhbz#1868347
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.
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
Tox calls socket.getfqdn() and that call does a DNS query.
In mock with disabled networking, it takes a minute until that times out.
When a spec file uses %pyproject_buildrequires -t and %tox, it is a 3 minute delay.
Since 3.17, tox does not call socket.getfqdn() when HOSTNAME variable is set to a value:
https://github.com/tox-dev/tox/pull/1616
The value is only used in result log, so setting it to "rpmbuild"
actually makes the logs more reproducible as well.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1856356
when tox is used in %pyproject_buildrequires -t or %tox.
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>
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.
