Amending PEP 427 (and PEP 625) on package normalization rules

[CAM-Gerlach]

@vbrozik

If we want to allow namespaces for project names, we should standardise them properly and make them “official”.

Having namespaces would be great! IMHO It should be standardised. We can hear how difficult it could be to get a suitable project name:

There is PEP 423 which is somewhat related, but it is from 10 years ago, Informational and Deferred indefinitely. Nevertheless, it may provide some useful foundations for such an effort.

PEP 423 – Naming conventions and recipes related to packaging | peps.python.org

@vbrozik

…and allowing hierarchy in import names (using namespace import packages) is only a good thing.

In theory, though it does create a number of tooling issues in practice.

@pf_moore

It would be an extremely useful fundable packaging project, IMO, to get these two PEPs rolled out. I created Add ‘Implement metadata PEPs’ by pfmoore · Pull Request #48 · psf/fundable-packaging-improvements · GitHub to suggest it.

I was about to suggest that, but you were way ahead of me

Not only that, but as we’ve discussed before, because the Metadata-Version is sequential, PEP 643 also blocks adoption of PEP 685, PEP 639 (which I’m about to release a new version of today, finally) and any future metadata changes.