On 19-08-2023 22:13, Miro Hrončok wrote:
On 19. 08. 23 19:44, Maxwell G wrote:
Hi Pythonistas,
%pyproject_save_files automatically handles marking license files
with %license when a build backend installs them into a package's
dist-info directory and the License-File header is specified in the
METADATA file. Currently, only setuptools and hatchling meet this
criteria. Notably, poetry and flit do not support this. They will
install license texts into the dist-info directory, but they do not add
the License-File metadata. The License-File tag is not standardized, and
discussion on PEP 639 which defines this standard has stalled. I believe
relying on this feature is a problem, as if a project changes build
systems or some other config and a packager doesn't realize, suddenly
the license file won't be marked with %license or even worse, not
installed at all. Since the pyproject macros read the build backend from
pyproject.toml without packagers having to manually specify anything
(which is generally great!), this situation seems likely to occur.
Until these issues are resolved, I propose banning this in Fedora and
requiring packagers to manually mark files with %license or at least
adding a large warning to the Packaging Guidelines. It can be similar to
the `'*' +auto` flags which are used by pyp2spec for automatic PyPI
builds in Copr but not allowed in Fedora proper.
What do y'all think? Am I missing something?
Hey. Alternatively to banning this: what if we make
%pyproject_save_files fail without a license? Obviously, that would be a
breaking change, so it could be opt-in first.
%pyproject_save_files -l ...
When used like this, no License-File header would result in an error.
We could introduce a reverse flag -L (don't fail without a license), and
have a discussion about changing the default later.
The guidelines could than say something like: If there is a license file
you MUST do one of the following when using %pyproject_save_files:
1) use -l and don't list it in %files explicitly
2) use -L and list it in %files explicitly
That way, we ensure the license is packaged (and marked as %license)
while not reducing automation.
I like that idea and I have a preference for -l being the default. That
way I don't have to manually verify if a license is present post build,
which I find myself doing reviewing packages that don't use an explicit
%license.
This might be out of scope, but would it also be possible to have it
fail or issue a warning if %pyproject_save_files -l marks a license, but
the packager also uses an explicit %license in %files. That would
prevent duplication.
-- Sandro
_______________________________________________
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, report it:
https://pagure.io/fedora-infrastructure/new_issue
