[Distutils] Deprecate and Block requires/provides

[Nick Coghlan]

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.

> 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.

> 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?

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.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia