Open edmorley opened 1 year ago
Hmm so this might be fixed by: https://github.com/pypa/hatch/pull/576
Pyroma is referring to the License
core metadata field (which is mapped to license.text
key in the [project]
table, and license
in most other tool-specific configs, e.g. setup.cfg
). If you set a string value directly for the license
key in Hatch, which implements my latest draft of PEP 639, that is used to set the License-Expression
core metadata field. I do include an optional provision allowing, but not requiring tools to also backfill the License
field with the same value, but I assume Hatch does not choose to do that. Therefore, Pyroma will not directly detect it.
PEP 639 is a draft spec, and I need to finish at least one last round of (mostly non-content-relevant changes) and potentially some additional feedback, before it is considered for acceptance and final implementation, so it seems premature for Pyroma to support it yet. Sorry for the delay! However, when it does, Pyroma should detect (and perhaps validate) it.
Thank you for the fast reply! I'd missed that PEP 639 is still a draft - Hatch's docs suggest using the new string form project.license
field, so I had presumed it was finalised.
I've filed https://github.com/pypa/hatch/issues/679
Thanks, I've replied over there. We could leave this open as a reminder if/when PEP 639 is accepted, or we could close this for now.
We could leave this open as a reminder if/when PEP 639 is accepted, or we could close this for now.
Whichever you prefer; either works for me :-)
Up to @regebro
Let's leave it open.
This project has a
license
defined under the[project]
table inpyproject.toml
: https://github.com/heroku/sf-functions-python/blob/a7541831525ae1850ae2c8511d2b0c8f94597a53/pyproject.toml#L10However, pyroma 4.1 on macOS using Python 3.11.0 reports that no license was specified: