[Distutils] Deprecate and Block requires/provides

[Noah Kantrowitz]

On Oct 17, 2013, at 3:50 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> 
> On 18 Oct 2013 04:48, "Donald Stufft" <donald at stufft.io> wrote:
> >
> > On Oct 17, 2013, at 2:33 PM, Noah Kantrowitz <noah at coderanger.net> wrote:
> >
> > >
> > > On Oct 17, 2013, at 9:26 AM, Michael Foord <fuzzyman at gmail.com> wrote:
> > >
> > >>
> > >>
> > >>
> > >> On 17 October 2013 16:53, Donald Stufft <donald at stufft.io> wrote:
> > >>
> > >> On Oct 17, 2013, at 11:49 AM, Michael Foord <fuzzyman at 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 at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20131017/87b74b26/attachment.sig>