Are you saying that there’s a chance we shouldn’t change the extension when introducing the new format? If so, what’s the scenario? This would need to something be better than “I don’t know since we haven’t designed that yet, but it might”. It is impossible to argue against speculation, and it is the speculating side’s responsibility to prove it, not the receiving end of it.
The proof also would be very needed for the whole sdist discussion; otherwise it will always run in circles: every partial design is shut down because we may want it done otherwise if everything is fully designed, without any indication of what that full design actually is. This is frustrating since the comment is always so easily made without any responsibility to prove it true, while the the other side has no way to object.
Assuming we will have a new extension when the sdist format is done, all churn required now will still be required. Unless you think a new extension would be a bad idea (again, proof required), the work relating to it is unavoidable, and does not change whether we do it now or later.
This is the current specification in its full:
- The file name is the
{name}-{version}.{ext}.{name}may or may not be normalised.{version}may or may not be normalised. It may or may not be compliant to PEP 440.{ext}is eithertar.gzorzip.
- It is an archive. There are files in it.
Honestly I think PEP 517’s Source distribution section is enough as a specification of the current situation.