<p dir="ltr"><br>
On 18 Oct 2013 08:55, "Donald Stufft" <<a href="mailto:donald@stufft.io">donald@stufft.io</a>> wrote:<br>
><br>
><br>
> On Oct 17, 2013, at 6:50 PM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>
><br>
>> And to me. A general "Evolution of PyPI APIs" process PEP could be a very helpful thing to avoid having to rehash this discussion for every change :)<br>
><br>
> PEPapolza</p>
<p dir="ltr">One PEP, two PEP, three PEP, more PEP :)</p>
<p dir="ltr">It occurs to me the numbering for new process PEPs is different from normal. Still, just a matter of looking at PEP 0 to pick the right subrange. </p>
<p dir="ltr">>> Given that PyPI doesn't have releases as such, perhaps we could tie this to the feature release cadence of pip? And officially recommend twine as the upload tool over using distutils directly? (Is twine ready for that at this point?)<br>

><br>
> Possibly, but I think it probably makes more sense to just do date based. Individual proposals can include special casings that depend on a release of a piece of tooling if it makes sense for that proposal.</p>
<p dir="ltr">That works, too.</p>
<p dir="ltr">><br>
>> The only other thing I would add is that when previous output is /dev/null'ed we may want to have a placeholder for a while with a link to an explanation for the removal.<br>
><br>
> A placeholder where? On the PyPI UX or something?</p>
<p dir="ltr">Yeah, I was thinking of the part at the bottom of the package info page that currently displays this metadata.</p>
<p dir="ltr">Cheers,<br>
Nick.</p>
<p dir="ltr">><br>
><br>
> -----------------<br>
> Donald Stufft<br>
> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA<br>
><br>
</p>