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

["Martin v. Löwis"]

> 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