<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>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.<br>
</p>
<br>
<div class="moz-cite-prefix">Donald Stufft kirjoitti 19.12.2017 klo
21:43:<br>
</div>
<blockquote type="cite"
cite="mid:85D70439-821D-4046-B7D9-7158B38E7384@stufft.io">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
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.
<div class=""><br class="">
</div>
<div class="">This issue was raised in <a
href="https://github.com/pypa/warehouse/issues/2170" class=""
moz-do-not-send="true">https://github.com/pypa/warehouse/issues/2170</a>. 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.</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">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 <a
href="https://github.com/pypa/warehouse" class=""
moz-do-not-send="true">https://github.com/pypa/warehouse</a> 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.</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Distutils-SIG maillist - <a class="moz-txt-link-abbreviated" href="mailto:Distutils-SIG@python.org">Distutils-SIG@python.org</a>
<a class="moz-txt-link-freetext" href="https://mail.python.org/mailman/listinfo/distutils-sig">https://mail.python.org/mailman/listinfo/distutils-sig</a>
</pre>
</blockquote>
<br>
</body>
</html>