> 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. > 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. 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. > 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 http://mail.python.org/mailman/listinfo/catalog-sig
