On 18 Oct 2013 04:48, "Donald Stufft" <don...@stufft.io> wrote: > > On Oct 17, 2013, at 2:33 PM, Noah Kantrowitz <n...@coderanger.net> wrote: > > > > > On Oct 17, 2013, at 9:26 AM, Michael Foord <fuzzy...@gmail.com> wrote: > > > >> > >> > >> > >> On 17 October 2013 16:53, Donald Stufft <don...@stufft.io> wrote: > >> > >> On Oct 17, 2013, at 11:49 AM, Michael Foord <fuzzy...@gmail.com> wrote: > >> > >>> Package upload certainly worked, and that is what is going to be broken. > >> > >> So would you be ok with deprecating and removing to equal "this metadata silently > >> gets sent to /dev/null" in order to not break uploads for what would have affected > >> roughly 4% of the total new releases on PyPI in 2013. > >> > > > > My vote on this whole thing in the general context of how to handle deprecating metadata fields > > * Email anyone using deprecated metadata at the time of deprecation (or now, in the case of this stuff) > > * Deprecation would follow a somewhat normal arc: > > * Initially it is just marked as deprecated in the docs (pending deprecation phase). > > * "One major release" (which is fuzzy in this case, but 6-12 months) later it goes to dev null on input and is removed from all output. > > * "One major release" later it is a fatal error. > > > > Having this whole schedule formalized will help everyone to know how we evolve the metadata spec, and because it is key-value pairs we have some wiggle room to sometimes ignore certain keys or treat them as opaque blobs (a la HTTP/MIME headers). In the case of this instance, I would say we should do the email and dev-null-ing immediately and then just pick up as normal and in 6-12 months (whatever we decide, not that it should actually be an ill-defined time period) it becomes a fatal error. > > > > --Noah > > > > _______________________________________________ > > Distutils-SIG maillist - Distutils-SIG@python.org > > https://mail.python.org/mailman/listinfo/distutils-sig > > This sounds reasonable to me.
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 :) 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?) 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. Cheers, Nick. > > ----------------- > Donald Stufft > PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA > > > _______________________________________________ > 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
