Ah, my mistake, I have sdists on the mind lately .
It might be worth its own thread to work out the details. The main thing I’d be concerned with about including it in METADATA would be that you’d need to either have a relative or absolute path to the files, which might make it so that the METADATA file is not trivially portable (can’t move around if you have paths relative to METADATA, can’t move around how files are arranged as part of the installation if it’s relative to repo root, need to generate a new METADATA file in each installation location if it’s an absolute path).
I’d expect the relative path to be of the same value as the first column in RECORD, i.e. relative to the installed site-packages directory, or the wheel’s archive root. Wheels are constructed as such that the relative path won’t change on installation, although I’m not sure whether it is a guarenteed feature.
I would expect the paths would be relative to the METADATA file itself, because they exist in the same directory. In most cases I can imagine, they would simply be filenames. E.g. for pip:
In METADATA it would say: LICENSE.txt. You can move the dist info directory around. Technically, if you just move the METADATA file in isolation to a random place, suddenly you no longer know the path for the licenses, but that applies to a lot more things (such as you no longer know the paths to files installed by the project if you move the RECORD file). So I don’t consider this a big issue.
The other changes include:
specifying a License-File field which is already used by wheel and setuptools to include license files in built distributions.
defining how tools can validate license expressions and report warnings to users for invalid expressions (but still accept any string as License).
.
