Primarily it’s naming. For instance, if you look at the code in pip to find the version number from an sdist you will notice it is not exactly based on a spec. Compare that to wheels where it’s very obvious how to get the version from the file name. This came up when I was trying to create a package to consume the simple repository API and wanted to group files by version and realized you can only reliably do that for wheels.
There’s also the issue of inconsistent file extensions. Once again, if you look at pip it looks for
.zip. That’s isn’t specified anywhere (closest is “whatever PyPI won’t reject upon upload”). This came up due to the simple repository API consumption package work and realizing there isn’t actually a way to group files into “wheels”, “sdists”, and “other” as there is no definition of what an sdist file extension is.
Due to the lack of clear file name extension support, there’s also no clearly defined preference around archive format and/or compression. Once again, it currently is “whatever PyPI takes” which isn’t tightly spec’ed anywhere. E.g. the default is
.tar.gz but I believe
.zip is still allowed. It also doesn’t allow for using e.g. zstd for those they may want the better performance. IOW it’s sort of flexible in letting you choose a tarball or a zipfile, but not in that it is only those two options and not for any specific reason while not letting in other alternatives. This came about because I realized that we have no support for zstd in the packaging ecosystem, and yet we also let sdists be either of a couple of possibilities, which felt oddly flexible yet restrictive all at once.
After that an sdist is a source archive that pip can build. Once again, not a spec. If we said “that has a pyproject.toml” at least that’s enough of a spec to actually be able to do something based on PEPs. Or if that was amended to “pyproject.toml or a
python setup.py bdist_wheel works with setuptools and wheel installed and there will be a wheel in the
dist directory” that’s still more of a spec than what we have now.