I’ve no idea. From a standards point of view, the PEP is OK, but maybe a clarification would be worthwhile.
For the practical matter of how we start enforcing the PEP, that’s down to individual projects. Pip defers to packaging, so we’re OK (in a “not our problem” sense ). But I don’t have a particular view on what (for example) packaging or poetry should do.
Regarding Ignore period for version parse · Issue #4176 · python-poetry/poetry · GitHub, I would say:
- Poetry’s interpretation of the PEP is correct.
- As I say, it’s not technically pip that’s letting these things work, that comes from the way packaging handles legacy version specifications. I understand that’s an unhelpful distinction from an end user point of view, though.
- Deprecation of the legacy form of specification is something that the packaging project will ultimately do, but how they handle that deprecation will be up to them. I’m not a maintainer of that project, so I don’t know what their plans are.
- Projects like poetry which don’t use packaging directly need to have their own process for handling legacy metadata, and that’s not a standards issue.
Personally, I think we’re going to have to bite the bullet and break compatibility at some point, but we should do a significant communication and outreach exercise to let the community know, and to help users deal with the inevitable fallout. But PyPA isn’t organised in such a way that we can handle such activities, so I don’t know how that can happen without a governance change (turning PyPA into much more of an “authority” than it currently is).
Don’t take any of the above as anything other than my personal opinion. My only “official” role here is around how we manage any change to the various standards (which as I say is just a matter of possibly clarifying the existing intent).