For reference, packaging's implementation is at https://github.com/pypa/packaging/blob/main/src/packaging/licenses/__init__.py, and it was based on Hatchling's implementation IIRC.

Is Flit actually compliant with PEP 639 if it doesn't accept valid SPDX expressions? I don't think the assumption that most Python projects have only one license is accurate. Even this project has multiple licenses. The project itself is BSD-3-Clause but it also includes BSD-2-Clause code in https://github.com/pypa/flit/blob/main/flit_core/flit_core/versionno.py (if not other code under other licenses in other places), so the correct license expression would be BSD-3-Clause AND BSD-2-Clause.

Can Flit not use (a vendored copy of) the hatchling-derived code in packaging?

I think that would be a good starting point, that’s why I linked to it. :)

See @takluyver's comment in PR #707:

I'd like to consider doing an independent implementation of SPDX validation & case normalisation. Besides preserving the zero-dependency status, this also means the ecosystem has two versions used in earnest to compare, rather than everyone doing the same thing. In a similar vein, Flit implements its own parsing of the PEP 621 [project] table, construction of the metadata file and wheel file structure, even though these are libraries that could provide these. I also like that when there's a bug, it's just a bug to fix, not an incompatibility with dependency X version Y.

Flit could vendor the packaging algorithm, but it is a good point that more implementations is not a bad thing.

A

I don't like the eval in the hatchling/packaging algorithm, and was going to write my own version for pyproject-metadata, but it proved to be a lot longer (the eval one is pretty clever), and when packaging came out, I just decided to use that (since pyproject-metadata does depend on packaging, unlike flit-core). But that might still be nice to try.