pip show does not recognise pyproject.yaml Licenses

[Lasitrox]

Description

Hi all,

I am trying to create an SBOM for our software, but lots of pip packages are not recognized.
I am using sbom4python which intern uses pip show to get the license for the packages.
I found that pip show does not work for some/most/all? packages that are using pyproject.toml.
pip show is looking for the "License" field in the package metadata, but pyproject.toml doesn't seem to set that. And depending on how the pyproject.toml is structured the metadata seem to be different.

Some versions I gathered with these issues:
Flask 2.3.3, 3.0.3
attrs 23.2.0
aiosqlite 0.20.0

Expected behavior

No response

pip version

24.1.2

Python version

3.11.5

OS

Windows 10

How to Reproduce

pip install flask
pip show flask

Output

Name: Flask
Version: 3.0.3
Summary: A simple framework for building complex web applications.
Home-page:
Author:
Author-email:
License:
Location: -
Requires: blinker, click, itsdangerous, Jinja2, Werkzeug
Required-by:

Code of Conduct

• I agree to follow the PSF Code of Conduct.

[RonnyPfannschmidt]

the metadata in the projects you mention is incomplete and stored in the correct expected manner

[matthewhughes934]

my understanding: pip is not responsible for collecting information from pyproject.toml into package metadata, that is the job of the build tool.

in the case of flask: it uses flit_core.buildapi as a build backend https://github.com/pallets/flask/blob/a8956feba1e40105e7bc78fa62ce36c58d1c91e1/pyproject.toml#L48 that backend doesn't store the license when collecting metadata (though if the license is a file it does include that file somewhere in the metadata) https://github.com/pypa/flit/blob/e38b172ca415e0b41c82801131d4e09a51e4bd85/flit_core/flit_core/config.py#L509. From what I understand (based on that comment and reading around a bit https://peps.python.org/pep-0621/, https://packaging.python.org/en/latest/specifications/core-metadata/) there's no standard definition (yet, see PEP 639 (in draft)) for how the details of a license should be stored in the package metadata (or if it needs to be captured at all), so doing nothing with it seems like a valid approach

[Julian]

I think this is a duplicate of #6677 -- and in particular I think I agree personally this is an issue for the reason mentioned there, notably that this is inconsistent with the packaging recommendations which recommend not supplying this field in favor of the classifier, but it's not obvious to someone doing so that they'll lose this output (I only noticed because a unit test checking this specifically failed!).

But it seems like the conclusion of that issue is to wait for PEP 639.

(TL;DR I think this issue should be closed as dupe, and that the other issue is waiting on PEP 639 to my understanding).

[ichard26]

(TL;DR I think this issue should be closed as dupe, and that the other issue is waiting on PEP 639 to my understanding).

Sounds good. 👍

FYI the third round of discussions on PEP 639 have recently concluded and we are awaiting a pronouncement from Brett. If you wish to read the PEP and make any suggestions or offer any feedback, you should get on that soon.