Couldn't Warehouse validate the description, and reject the upload (with
an appropriate message) if it doesn't pass? This at least would
eliminate those ugly project pages that failed to render...there are a
lot of them on PyPI.
Donald Stufft kirjoitti 19.12.2017 klo 21:43:
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. 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 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
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
