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?
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.
On Sat Aug 19, 2023 at 22:13 +0200, 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:
- use -l and don't list it in %files explicitly
- 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 -l flag idea, but I don't think we can make it fail by default for the foreseeable future, given the status of PEP 639 and build system adoption. We could use a heuristic (such as a hardcoded list of globs) to match license files in dist-info directories if License-File doesn't exist, but I'm not sure that's the best idea. I'm hesitant about adding a noop -L flag until we actually have a plan/criteria on when to start enforcing -l, but I don't feel strongly.
On Sat, Aug 19, 2023 at 4:58 PM Maxwell G maxwell@gtmx.me wrote:
On Sat Aug 19, 2023 at 22:13 +0200, 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:
- use -l and don't list it in %files explicitly
- 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 -l flag idea, but I don't think we can make it fail by default for the foreseeable future, given the status of PEP 639 and build system adoption. We could use a heuristic (such as a hardcoded list of globs) to match license files in dist-info directories if License-File doesn't exist, but I'm not sure that's the best idea. I'm hesitant about adding a noop -L flag until we actually have a plan/criteria on when to start enforcing -l, but I don't feel strongly.
-- Maxwell G (@gotmax23) Pronouns: He/They _______________________________________________ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-leave@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.fedoraproje... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
I like this plan overall. The only part I would adjust is the guidelines having a MUST requirement to use one flag or the other. Fewer required flags is better, which is why we would have a default at all. I'm totally fine with a transition to making the default behavior to fail if a license isn't found. The guidelines can say that packages should use `%pyproject_save_files -L` if it is known that it won't detect a license and it will be specified manually with %license in %files, which will be a noop now but will prevent packages from FTBFS when we make the switch.
On 19. 08. 23 23:57, Maxwell G wrote:
On Sat Aug 19, 2023 at 22:13 +0200, 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:
- use -l and don't list it in %files explicitly
- 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 -l flag idea, but I don't think we can make it fail by default for the foreseeable future, given the status of PEP 639 and build system adoption. We could use a heuristic (such as a hardcoded list of globs) to match license files in dist-info directories if License-File doesn't exist, but I'm not sure that's the best idea. I'm hesitant about adding a noop -L flag until we actually have a plan/criteria on when to start enforcing -l, but I don't feel strongly.
I've drafted the implementation:
https://src.fedoraproject.org/rpms/pyproject-rpm-macros/pull-request/422
The -l flag asserts at least 1 License-File is present. The -L flag disables the assert (i.e. it does nothing).
I was considering the idea that the -L flag would assert no License-File was found, but I don't think that will be that useful.
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
On 23. 08. 23 13:17, Sandro wrote:> 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.
Unfortunately, the macro have no way of knowing what is included in %files manually, co I am afraid this is not possible to implement.
On 8/23/23 18:34, Miro Hrončok wrote:
On 23. 08. 23 13:17, Sandro wrote:> 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.
Unfortunately, the macro have no way of knowing what is included in %files manually, co I am afraid this is not possible to implement.
This should be possible to detect in Zuul, if you use it, because the rpm-linter there raises an error if it finds a duplicate files.
Lumír
python-devel@lists.fedoraproject.org
-
Carl George -
Lumír Balhar -
Maxwell G -
Miro Hrončok -
Sandro