For those who are not aware, legacy PyPI would allow you to run ``twine
register`` on a release that had already been created in order to modify the
metadata that PyPI had recorded for that release (keyed by version number).
This wasn’t a super widely used feature, but it’s primary use case was when
folks would mistakenly release a project that had a broken description that
wouldn’t correctly render on PyPI. With the move from the legacy PyPI code base
to Warehouse for handling uploads, this feature had been somewhat inadvertently
lost.
This issue was raised in https://github.com/pypa/warehouse/issues/2170
<https://github.com/pypa/warehouse/issues/2170>. This email is provide notice
that after thinking about this issue for awhile, we’re *not* going to restore
the ability to modify the metadata associated with a release after it has been
uploaded.The eventual goal is that it should be ideally possible to treat the
files that are on PyPI as the source of truth for all metadata, and that the
data stored in the database is simply an optimization for accessing and
presenting that data on PyPI. Obviously if we allow modifications to the
metadata as stored in the PyPI database, that would allow this metadata to
“drift” from what is actually stored in the files, which would prevent that
goal from being realized.
It is true that even with this change, there is not a guarantee that the
metadata in the database does not match what is in the file(s) that have been
uploaded to PyPI, even going into the future. Thus the decision to not restore
this feature is not the only step on the way to being able to assert this
guarantee, but it is *one* of them.
The most common reason for wanting to modify any metadata after the fact is to
fix typos etc that made it into the description prior to publication. It is our
opinion that the best way to handle these is to either cut a new release (it
can be a post release if that’s all that has changed) or to validate the
description field prior to publication (which can currently be done using
readme_renderer or restview). Longer term we also plan to introduce the ability
to “stage” releases so that releases and files can be uploaded to a temporary
location within Warehouse, and visible with a special URL to allow people to
manually validate the actual bits that were uploaded before pushing a
“finalize” or “publish” button that would flip it from being a mutable, hidden
release to an immutable, publicly viewable release.
If folks have other use cases where they’ve used the ability to modify release
metadata after it had been released that they feel is an important enough use
case that it needs to be supported in some way, please let us know either in
this thread or by opening an issue on https://github.com/pypa/warehouse
<https://github.com/pypa/warehouse> so we can figure out if it’s something we
want to support, if one of the other mechanisms we’re planning on adding will
support it, or if there is some new mechanism we can add that can support it
better.
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
