On Oct 17, 2013, at 3:50 PM, Nick Coghlan <ncogh...@gmail.com> wrote:
> > 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 :) +1, especially because the process is asymmetric, pip needs to accept and silently ignore unknown metadata fields indefinitely. --Noah
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
