search

python / typing_extensions

Backported and experimental type hints for Python
Other
445 stars 109 forks source link

Change license identifier in project metadata to text #451

Open mschoettle opened 3 months ago

mschoettle commented 3 months ago

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

cpython-cla-bot[bot] commented 3 months ago

All commit authors signed the Contributor License Agreement.
CLA signed

srittau commented 2 months ago

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?

mschoettle commented 2 months ago

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.

srittau commented 2 months ago

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.

JelleZijlstra commented 2 months ago

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.

srittau commented 2 months ago

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.

mschoettle commented 2 months ago

Waiting for PEP 639 makes sense to me.

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

AlexWaygood commented 4 days ago

Has this been superseded by #507?

mschoettle commented 3 days ago

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

cdce8p commented 2 days ago

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.