On Oct 17, 2013, at 11:36 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
> Indeed - the metadata PEPs really aren't aimed at end users. Until > something is marked as deprecated in the CPython docs, and actually > deprecated in the standard library, it isn't really deprecated :) > > We can at least do a documented deprecation in the CPython docs when > we're implementing the PEP 453 documentation updates (I'll hopefully > get the Windows path changes in this weekend sometime, and after that > it should finally be ready for MvL's formal pronouncement) Ironically the documentation shows how confusing it is because for someone new coming into packaging that documentation reads like this is what you put in in order to depend on other things. I would challenge anyone to write docs that aren't confusing that actually explains what requires actually does. So again I ask what I need to do to deprecate and remove requires, provides, obsoletes. Do I need to make a PEP? Do I need to make a bug tracker issue and a patch? What's the path forward. Can we at least agree that these can removed? obsoletes_dist - Never been used, never been implemented besides in Distutils2 requires_external - Used 9 times by 1 project, never been implemented outside of Distutils2 requires_python - Used 61 times, never been implemented outside of Distutils2 These either have a different method of supporting them in PEP426 (and thus keeping around two ways of doing the same thing is confusing, especially when it was never formally implemented) or were omitted completely. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
