PEP 639, Round 2: Improving license clarity with better package metadata

Delays due to moon launch responsibilities are acceptable I guess :stuck_out_tongue_winking_eye:


As long as he’s not saying Laika ate his homework I guess that’s a good enough excuse.


Any update?

Hey @CAM-Gerlach congrats for sending the rocket towards the Moon and not crashing it!
@thatch and I are back on the saddle and willing to help usher this through the finish line.
You have done an enormous amount of work there!
What can we do to help?
What is your latest PR?


One thing that came up in hatch’s issue tracker: Custom files under `dist-info` as part of a build hook · Issue #620 · pypa/hatch · GitHub

Currently, this PEP defines a directory for storing license files under the .dist-info folder, in a sub-folder. In the discussions back when installer’s scope/API was being figured out, @dholth pointed out that (at least, by design) the files in dist-info should be treated like a dictionary of name-of-file: text-contents-of-file with no directories expected in there (and, that was somewhat baked-into the API design of installer).

I’m mentioning this to elevate from those discussions that this is a semantic change we’d be making to how dist-info works, which could lock us out of potential data structures for storing metadata info in that, and other stuff like that, in the future.

I don’t personally have strong opinions on this; the pip/installer side of this is relatively straightforward to deal with, and I’m fairly certain that they already do – but I’m not sure if everyone is fine with making this change for tooling. It’s certainly worth calling out in the PEP as well. :slight_smile:

I also don’t have a strong opinion here, beyond that we shouldn’t just make assumptions, we should agree and document a position, one way or another.

The spec for the .dist-info directory says “Additional installer-specific files may be present”. That doesn’t explicitly prohibit directories, but it could be viewed as implying “files only, no directories”. The wheel spec says nothing about this, as far as I can tell.

Does anyone know of any existing wheels or installed projects that have subdirectories in .dist-info? My database of PyPI data doesn’t currently include wheel contents, so I can’t check this myself.

If we’re allowing custom (whether backend or user defined) files in .dist-info, then we have a potential backward compatibility issue whenever we add new files. For example, the proposal here for a licenses directory would be incompatible with a custom file called licenses. This isn’t mentioned in the PEP’s “Backward compatibility” section, by the way… A way round this would be to reserve all top level names (maybe explicitly noting that setuptools adds a number of non-standard names, which will remain for compatibility) and require all non-standard metadata files to go in a custom subdirectory. That means accepting that subdirectories are allowed.


Directories would be fine.

I would like to see new keys in the .data/ directory to mark categories of files.


Hey all, is there any update on this? I’ve now ran into multiple situations where having this PEP active would be helpful.

1 Like

It’s waiting on @CAM-Gerlach to finish his next draft of the PEP for review.

1 Like