> On Jul 25, 2016, at 3:05 PM, Chris Barker <[email protected]> wrote: > > On Mon, Jul 25, 2016 at 8:55 AM, Robin Becker <[email protected] > <mailto:[email protected]>> wrote: > In our private readonly pypi we have 93 releases. I don't think that burden > should fall on pypi. However, it's not clear to me if I should push micro > releases to pypi and then remove them when another release is made. Is there > a way to remove a 'release' completely? > > I'm pretty sure there is no way to remove a release (at least not routinely). > thi sis by design -- if someone has done something with that particular > release, we want it to be reproducible.
Authors can delete files, releases, or projects but can never re-upload an already uploaded file, even if they delete it. It is discouraged to actually do this though (and in the future we may change it to a soft delete that just hides it from everything with the ability to restore it). It is discouraged for basically the reason you mentioned, people pin to specific versions (and sometimes specific hashes) and we don’t want to break their deployments. > > I see the point, but it's a little be too bad -- I know I've got some > releases up there that were replaced VERY soon due to a build error or some > carelessness on my part :-) > > Apparently, disk space is cheap enough that PyPI doesn't need to worry about > it. Disk space is super cheap. We’re currently using Amazon S3 to store our files, and the storage portion of our “bill” there is something like $10/month for all of PyPI (out of a total “cost” of ~$35,000/month). Almost all of our “cost” for PyPI as a whole comes from bandwidth used not from storage. — Donald Stufft
_______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
