[Catalog-sig] Proposal: close the PyPI file-replacement loophole

[Donald Stufft]

I'm very much +1 on this. I don't see any use case for modifying a file after it was already released. It means that if I install version 1.0 of a package today, tomorrow version 1.0 of a package might be different and introduce incompatibilities. It lowers the ability of anyone using PyPI or it's mirrors to be secure in the fact that when they tested their application with versions X,Y,Z of a library, that it should continue to work exactly the same with versions X,Y,Z as a library.

There isn't a limited set of version numbers, if someone makes a mistake on packaging the can delete the file, and increase the version number.  


On Sunday, January 29, 2012 at 7:38 PM, "Martin v. Löwis" wrote:

> > When we initially implemented file upload to PyPI it was our intention
> > that the file be immutable once uploaded. The goal was to make things
> > significantly simpler for end users - there would only ever be one
> > file with a given name. If the content changed then so must the name
> > (typically by creating a new release version.)
> >  
>  
>  
> I don't actually recall that being a goal :-)
>  
> > Your thoughts?
>  
> -1. There are plenty of ways to check whether the file was modified if
> you already have a copy of it. Users just need to accept that files may
> change, and package authors need to accept that users may retain old
> copies of a file even after they replaced it.
>  
> I just got a user comment a week ago of a user explicitly thanking about
> the ability to replace files after already publishing them.
>  
> Regards,
> Martin
> _______________________________________________
> Catalog-SIG mailing list
> Catalog-SIG at python.org (mailto:Catalog-SIG at python.org)
> http://mail.python.org/mailman/listinfo/catalog-sig
>  
>  


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20120129/1f6248fb/attachment.html>