New release: pyproject-rpm-macros 0-46, new features and breaking changes

[Miro Hrončok]

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/8eacfa312d77aba28d483fbfb6...
>    /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: [phone]
IRC: mhroncok