Does PEP 376 need a review?

PEP 376 - Database of Installed Python Distributions was written in the days of the “distutils rewrite” work in Python, which ultimately got abandoned. However, the PEP was finalised and contains many details that are implemented in current packaging standards (the .dist-info directory format being an obvious example). But it also contains a lot of stuff that never got implemented and likely never will be (additional functions for the stdlib pkgutil module).

Should we have a review of PEP 376, to produce an updated version that documents the standards that we do follow (plus those that we should follow, but maybe don’t yet) and drops the stuff that will never be implemented or needed?

I’m rather uncomfortable with the feeling that some of our fundamental packaging standards are located in a PEP that has limited credibility because it documents many things that never got implemented :frowning: On the other hand, it’s likely to be a relatively big discussion that has limited value (it’s mostly just standards admin). Also, I don’t have the bandwidth myself right now to write up a modified PEP.

Thoughs? Maybe this is something that should be discussed at the packaging summit?

I think that PEP 376 was written before all the other PEPs and the distutils2 project.
It was always meant as a building block in the stdlib, and pkgutil was chosen to home the new functions.
When distutils2 was started to implement a bunch of PEPs + rework + reinvent PyPI + more things, a pkgutil module was copied in the repo and worked on. Later, when the idea was to have distutils2 on PyPI + something in the stdlib (named too generically «packaging», making it quite hard to refer to and search for, like modern pyca/cryptography and pypa/packaging projects :wink:), I suggested that we didn’t have to touch pkgutil anymore and we got distutils2.database:!searchin/the-fellowship-of-the-packaging/pkgutil|sort:date/the-fellowship-of-the-packaging/dtPj2AmBYt4/ihG3Sy8MbTIJ

I propose a short edit to PEP 376: add notes at the beginning and in the implementation details section to make that section non-normative, to explain that the spec part of the PEP is final, but the implementation didn’t go as expected.

1 Like

To avoid the big discussion you mention, this PR proposes to add notes rather than update the whole document:


Cool - yes, looking at the PEP again, it is as simple as just that. Thanks for both the background and the suggestion.


Does someone else who remembers that time want to add anything?
If not, the PR could be merged soon.

I’ve merged the PR. Happy to have any further changes added as follow-ups if someone missed the chance to comment.