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:
>
> 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 -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(a)lists.fedoraproject.org
To unsubscribe send an email to python-devel-leave(a)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.fedorapr...
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.
--
Carl George