No, you’re right (in a way). The problem with the existing standard is that it doesn’t allow for recognising a sdist in a context where you’re not already sure you have a sdist. And that means we might want to change the current standard. So yes, we can look at that as purely a question of “this is how you write sdist names in the future”. But I’m not clear how it helps - any new standard will be trivially parseable, because it can be, and why would we make it otherwise?
Yes - to get any benefit for tools, we need a new extension. That was the point of my comment above. We’re not going to standardise the heuristics for interpreting existing
.tar.gz filenames, precisely because they are heuristics. So tools will continue to do this regardless of any standard - and they already have the logic present. We may move “best practice” heuristics to a library like packaging or mousebender, but they won’t be a standard. They can be guaranteed accurate if you know you have a sdist conforming to PEP 517 naming, but degrading gracefully is really important, as we have no way of rejecting non-conformant names.
But as the only use case for PEP 625, standardising the filename before the internal structure, was to help tools reliably detect sdists and parse their names, if we can’t agree (yet) to use a new extension, then it should be withdrawn in favour of a future “standardise sdists” PEP.
Not “if it’s already specified”, but “if we aren’t going to get a new extension”. But otherwise yes.
It’s probably pip’s logic, and maybe should go to mousebender rather than packaging, but that’s optional, and it’s being worked on (I’m looking at it and I think Brett is too…)