On Fri, 25 Jun 2021, Jeremy Stanley wrote:
I feel like there is probably consensus against the use of PyPi-provided
upstream source tarballs in preference for what will usually be a GitHub
release tarball, so I made an MR to this effect (moderate recommendation
rather than a "must" directive):
https://salsa.debian.org/python-team/tools/python-modules/-/merge_requests/16
Comments, corrections, requests for additional information, and
objections welcome :-) I'm also curious if there isn't consensus by
this point and if it requires further discussion
I work on a vast ecosystem of Python-based projects which consider
the sdist tarballs they upload to PyPI to be their official release
tarballs, because they encode information otherwise only available
in revision control metadata (version information, change history,
copyright holders). The proposal is somewhat akin to saying that a
tarball created via `make dist` is unsuitable for packaging.
"GitHub tarballs" (aside from striking me as a blatant endorsement
of a wholly non-free software platform) lack this metadata, being
only a copy of the file contents from source control while missing
other relevant context Git would normally provide.
I tend to agree about PyPI being the official releases for a lot of
projects. "GitHub tarballs" also tend to include other undesirable stuff
for distribution like upstream CI/CD configuration files, etc.
Scott
