[Distutils] Deprecate and Block requires/provides

[Noah Kantrowitz]

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

-------------- 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/00013aa5/attachment.sig>