PyPI files should not change their payload (was: Announce: PyPrimes 0.2.1a)
ben+python at benfinney.id.au
Fri Jan 9 00:55:37 CET 2015
Steven D'Aprano <steve+comp.lang.python at pearwood.info> writes:
> I screwed up the upload to PyPI, and it won't allow you to upload the
> same version twice. (At least, I don't know of any way to do so.) So I
> had to bump the version number to re-upload.
There is currently a hack that can be done (I won't say what it is) to
upload a different payload with the same filename. Please don't do it.
This is widely regarded, and I agree, as a bug: once PyPI has a file of
a particular name (including the package version), that filename should
only ever refer to that same content and never anything else.
Over at ‘distutils-sig’, way back in 2014-09, a discussion reached the
consensus that the current undocumented ability to change the payload of
an existing file from PyPI is an oversight that needs to be closed
with the Python Packaging Authority making its position known at
Silently changing released artefacts is actively user hostile. It
breaks mirroring, it breaks redistribution, it breaks security
audits, and it can even break installation for security conscious
users that are using peep rather than pip.
I am thoroughly *against* retaining a general capability to silently
substitute the contents of previously released files with a
different payload solely to handle the case of packaging errors that
aren't otherwise severe enough to warrant bumping the version number
So, it seems you did the right thing in uploading different package
source content with a later version string.
The issue of remembering to update the Changelog document is another
matter, which I'll address in a different message.
\ “Capitalism has destroyed our belief in any effective power but |
`\ that of self interest backed by force.” —George Bernard Shaw |
More information about the Python-list