[Distutils] Deprecate and Block requires/provides

[Nick Coghlan]

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 :)

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 at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20131018/96091339/attachment.html>