typing_extensions icon indicating copy to clipboard operation
typing_extensions copied to clipboard

Change license identifier in project metadata to text

Open mschoettle opened this issue 1 year ago • 7 comments

I'd like to propose changing the license metadata to text with the license identifier "Python-2.0" reflecting the content of the LICENSE file.

License scanning tools such as the one GitLab uses rely on the license field returned by the PyPI API which returns license: null for this package (JSON).

Related to #62

mschoettle avatar Aug 23 '24 20:08 mschoettle

All commit authors signed the Contributor License Agreement.
CLA signed

ghost avatar Aug 23 '24 20:08 ghost

Thanks, it makes sense to me to use a classifier here. The documentation for pyproject.toml says to use of the license classifiers from the classifiers list (minus the prefix). But I can't find "Python-2.0" on that list?

srittau avatar Aug 29 '24 15:08 srittau

Unfortunately, the classifiers are ambiguous (or not complete) for some licenses (BSD, Python, Apache). See also here: https://github.com/pypa/trove-classifiers/issues/17. It seems that the classifiers are not taken into account for the license field that the PyPI API returns. With the license being specified as proposed by this PR the API returns the license field.

There is also now PEP 639 (provisional) which aims to improve this.

mschoettle avatar Aug 30 '24 13:08 mschoettle

I don't think we should use classifiers that contradict the official documentation. It's great to see that there's some progress to improve the license situation, but I'd prefer to wait until there's an officially accepted solution. But I'll defer the decision to @JelleZijlstra and @AlexWaygood here, as core developers and most active regarding typing_extensions.

srittau avatar Aug 30 '24 15:08 srittau

I am not very familiar with packaging arcana, but I'd prefer to avoid relying on any unspecified behavior, and instead use PEP 639 now that it's been provisionally accepted.

JelleZijlstra avatar Aug 30 '24 15:08 JelleZijlstra

I am not very familiar with packaging arcana, but I'd prefer to avoid relying on any unspecified behavior, and instead use PEP 639 now that it's been provisionally accepted.

That's the most sensible approach, but I don't think flit supports PEP 639 yet.

srittau avatar Aug 30 '24 15:08 srittau

Waiting for PEP 639 makes sense to me.

There is now a feature request for flit: https://github.com/pypa/flit/issues/692

mschoettle avatar Sep 03 '24 15:09 mschoettle

Has this been superseded by #507?

AlexWaygood avatar Nov 19 '24 12:11 AlexWaygood

Looks like it. Although it uses the old syntax, not the new one introduced by PEP 639 I think.

mschoettle avatar Nov 19 '24 13:11 mschoettle

Looks like it. Although it uses the old syntax, not the new one introduced by PEP 639 I think.

flit_core doesn't yet support the new syntax and would raise a ConfigError.

cdce8p avatar Nov 20 '24 23:11 cdce8p

Looks like flit just merged support for PEP 639. Hopefully that'll be released soon and we can upgrade.

JelleZijlstra avatar Feb 11 '25 03:02 JelleZijlstra

Looks like flit just merged support for PEP 639. Hopefully that'll be released soon and we can upgrade.

Flit 3.11 was released earlier today. Opened #530 to update the project metadata.

cdce8p avatar Feb 19 '25 12:02 cdce8p

Thanks @cdce8p. Closing this as it is superseded by #530.

mschoettle avatar Feb 19 '25 14:02 mschoettle