On Oct 17, 2013, at 12:03 PM, Nick Coghlan <ncogh...@gmail.com> wrote:
> On 18 October 2013 01:45, Donald Stufft <don...@stufft.io> wrote: >> >> 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. > > The docs don't have to explain what it does, they have to explain that > it's obsolete and shouldn't be used. Deprecating it in the metadata > PEPs isn't enough. I meant supporting the viewpoint that these fields are confusing, not supporting that they've been deprecated. > >> 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. > > The docs changes can probably be done as part of the PEP 453 docs updates. > > Emitting a deprecation warning in 3.4+ would need a patch on the > CPython issue tracker. Distutils already accepts arbitrary keyword values and prints a warning so I think all that would need to be done is to remove them and let the regular machinery take care of it. I can work up a patch for that. > >> 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. > > Sure, but what's the hurry? Is it just a matter of wanting to be able > to leave them out of the Warehouse data model? The "hurry" on these is less a hurry and more wanting to clear them out to prevent confusion. Warehouse is backed by the same schema that PyPI itself uses. If nobody (or practically nobody) is using them there's very little benefit to waiting to remove them. Cleaning up the database to try and remove some of the bit rot, bad ideas, deprecated and removed features is an ongoing process i've been engaged in. This is the area I was working on this morning. So it can wait, but I don't see a need to wait on these fields which will help clean up the DB. In this case when I came across these I thought about it and realized that these fields only really exist to confuse people and they should probably be removed out right. > > As I stated earlier, I'm essentially OK with PyPI rejecting these with > a clear error message and a pointer towards setuptools for *new* > projects. I'm only averse to breaking them for projects that already > have these populated in at least one release, and upload a new release > that still includes them. Are you fine with PyPI just discarding these pieces of metadata? > > Cheers, > Nick. > > -- > Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ----------------- 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
