Hello,
we have just released pyproject-rpm-macros 0-46 with new features and breaking
changes (2 affected Fedora packages, python-platformdirs and python-shellingham).
F35: https://bodhi.fedoraproject.org/updates/FEDORA-2021-a33e4b0558
F34: https://bodhi.fedoraproject.org/updates/FEDORA-2021-fcf5e2adc6
F33: https://bodhi.fedoraproject.org/updates/FEDORA-2021-3d06d86fe9
We aim to release version 1 before Fedora 35 is released: That should remove
the "provisional" status of the macros: we are extensively probing the design
decisions and plan to maintain a stable interface and behavior after that.
tl;dr version:
%pyproject_buildrequires now supports x.* versions.
In %pyproject_buildrequires, invalid requirements now *fail* the build.
%pyproject_buildrequires fallbacks to setuptools only if setup.py exists.
The requirements files parser is now more robust.
%pyproject_save_files now escapes weird characters.
%pyproject_save_files marks license files with %license.
The %{_pyproject_ghost_distinfo} and %{_pyproject_record} macros are private.
Details below:
---------------
%pyproject_buildrequires now supports x.* versions.
When a project requires e.g. "pkg==6.*", %pyproject_buildrequires now correctly
handles that by requiring "pytohn3dist(pkg) >= 6 with pytohn3dist(pkg) < 7".
---------------
In %pyproject_buildrequires, invalid requirements now *fail* the build.
Previously, they were skipped with a warning. Only one package in Fedora is
affected and a PR exists (python-platformdirs#1).
Failing the build for dependencies that cannot be processed via Python tools
(such as pip) is harmless: The package would eventually fail to build later in
the process anyway. However, some dependency declarations work with pip while
we cannot process them via the macros. From the README:
When a dependency is specified via an URL or local path, for example as:
https://github.com/ActiveState/appdirs/archive/8eacfa312d77aba28d483fbfb6f6fc54099622be.zip
/some/path/foo-1.2.3.tar.gz
git+https://github.com/sphinx-doc/sphinx.git@96dbe5e3
The %pyproject_buildrequires macro is unable to convert it to an appropriate
RPM requirement and will fail. If the URL contains the packageName @ prefix as
specified in PEP 508, the requirement will be generated without a version
constraint:
appdirs@https://github.com/ActiveState/appdirs/archive/8eacfa312d77aba28d483fbfb6f6fc54099622be.zip
foo@file:///some/path/foo-1.2.3.tar.gz
Will be converted to:
python3dist(appdirs)
python3dist(foo)
Alternatively, when an URL requirement parsed from a text file given as
positional argument to %pyproject_buildrequires contains the #egg=packageName
fragment, as documented in pip's documentation:
git+https://github.com/sphinx-doc/sphinx.git@96dbe5e3#egg=sphinx
The requirements will be converted to package names without versions, e.g.:
python3dist(sphinx)
However upstreams usually only use direct URLs for their requirements as
workarounds, so be prepared for problems.
------------
%pyproject_buildrequires fallbacks to setuptools only if setup.py exists.
In line with the recent development of pip (and build), when the build backend
is not specified (e.g. pyproject.toml is missing or does not specify it) the
setuptools.build_meta.__legacy__ build backend is only used if setup.py exists.
Projects without setup.py that intent to use setuptools need to explicitly
declare it in pyoproject.toml or add a setup.py stub, see e.g.
python-shellingham#5, the only affected Fedora package.
---------------
The requirements files parser is now more robust.
The %pyproject_buildrequires macro accepts requirements files as optional
position arguments. With this release, the parser for the files (also used for
tox dependencies) is more robust and should process comments, escaped newlines
and environment variables better than ever.
However, the parser is not (yet) 100% compatible with `pip install -r <file>`
behavior (and might as well never be). If you encounter incompatibilities,
please let us know.
---------------
%pyproject_save_files now escapes weird characters.
When a path contains spaces (incl. newlines), quotes (") or percentage signs
(%), it is now correctly escaped by %pyproject_save_files.
Note that due to the limitations of RPM, we are unable to represent a path with
both spaces and quotes. An error is raised when that happens, instead of
producing wrong results.
---------------
%pyproject_save_files marks license files with %license.
PEP 639 (still a draft) introduces a new metadata field for license files (the
License-File field). Setuptools 57+ generate the field from the license_file(s)
setup options. %pyproject_save_files newly recognizes this field and marks the
listed files with the %license tag. Other build backends might follow later.
If your package supports this, you no longer need to list the license file
manually. I recommend using `rpm -ql --licensefiles` to verify this before
removing the manually listed LICENSE file.
Note that in Fedora 33 and 34 we don't have setuptools 57+, so I only recommend
doing this for packages that don't do merges to stable Fedoras.
---------------
The %{_pyproject_ghost_distinfo} and %{_pyproject_record} macros now start with
an underscore to indicate they are "private": You should not use them in the
spec file unless working around some bug in pyproject-rpm-macros. If you ever
need to use the macros (or their value) in spec, consider contacting us first.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
