On Monday, January 30, 2012 at 4:31 PM, "Martin v. Löwis" wrote:
> > The mirror protocol, as far as I remember, does not deal with 'updates > > of existing files' > > > > > It most certainly does, and pep381client deals with it correctly. One of the mirrors doesn't deal with it correctly. I think the one on GAE? Has caused a lot of problems for me. > > > IOW if the release is broken and you fix it in pypi, it might stay > > broken in mirrorsand the inconsistent state is much more trouble. > > > > > No, it won't. The mirrors will notice that the package changed, and > recheck all files. The current implementation uses the ETag header > to determine whether a file changed, although looking for a changed > md5sum might be a better approach. > > > so +1 for creating a new release whatever state the previous published > > one is in - release numbers are not expensive > > > > > As a guideline to package authors, I can certainly agree with that. I > don't mind putting a note in the PyPI UI telling authors that file > deletion is consider a violation of the social contract. > > The issue at hand is whether to disallow recreation of deleted files > entirely. I see this as a maintenance nightmare: people first delete > the files (which we can't stop them from doing), then try to recreate > the file, and find out that this is rejected. > > Offhand I believe deleting the file requires using the web interface? If so it should be trivial to present a warning that states. "Are You Sure You Want To Do This? Note: You Will Not Be Able to Upload This Same FIle Again, You will Need to make a new release". > > Next, they try to delete the release entirely. Not sure whether Richard > intended to have the file deletion markage survive that also. If so, > they might try to delete the entire package, and re-register that. > > It should survive the lifetime of the package. I'd also argue that it should survive past it as this is a different but similar problem. (Someone pulls a _why/mark pilgrim and deletes all their releases, someone else takes this chance to grab the package name, and uploads malicious code. > > > what about adding a metadata flag to releases ? e.g. "deprecated" - > > that way client tools know they need to avoid this one > > and developers can change the flag > > > > > You mean, if a file is recreated, it is somehow flagged? Sounds fine > to me. > > Regards, > Martin > _______________________________________________ > Catalog-SIG mailing list > Catalog-SIG@python.org (mailto:Catalog-SIG@python.org) > http://mail.python.org/mailman/listinfo/catalog-sig > >
_______________________________________________ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
