[Distutils] Deprecate and Block requires/provides
donald at stufft.io
Thu Oct 17 18:13:42 CEST 2013
On Oct 17, 2013, at 12:03 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 18 October 2013 01:45, Donald Stufft <donald at stufft.io> wrote:
>> On Oct 17, 2013, at 11:36 AM, Nick Coghlan <ncoghlan at 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
> 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
> 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?
> Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the Distutils-SIG