[Distutils] Deprecate and Block requires/provides

[Nick Coghlan]

On 18 October 2013 00:24, Erik Bray <erik.m.bray at gmail.com> wrote:
> On Thu, Oct 17, 2013 at 9:53 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> Yes, but breaking these users' uploads is not the way to do that.
>> That's an incredibly user hostile step to take, and the problem
>> doesn't even come close to justifying breaking even a
>> not-really-working process (since you can work around the current
>> breakage by manually installing the dependencies - you can't work
>> around an inability to upload without making changes to your code).
>
> +1  I can imagine that from many users' perspectives "you're doing it
> wrong" isn't even true.  The docs for distutils *still* read:
>
> "Dependencies on other Python modules and packages can be specified by
> supplying the requires keyword argument to setup()"
>
> and
>
> "A package can declare that it obsoletes other packages using the
> obsoletes keyword argument"
>
> and nowhere does it read "but these keywords are broken and obsolete
> as of <some obscure PEP> and you're wrong to have used them".

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)

Cheers,
Nick.

>
>> If you really wanted to push them towards fixing their releases, you
>> could always have PyPI send them an email saying something like:
>>
>> "Hi, an automated scan of PyPI has shown that you're currently
>> uploading metadata that uses the obsolete module dependency fields
>> defined by distutils. These fields aren't actually checked by
>> automated installation tools like pip, so if you're attempting to
>> indicate that your project depends on other PyPI projects, this
>> mechanism doesn't actually work to achieve that.
>>
>> At some point in the future, PyPI may disallow use of these fields
>> entirely, so if you'd like to declare your dependencies in a way that
>> automated tools can process, you may want to look at using the
>> dependency declaration features in setuptools rather than using plain
>> distutils".
>
> I was just going to ask--why not at least try to e-mail the
> maintainers of those packages?  If they're unreachable to begin with
> then I'm a little less concerned.  But at least give those who might
> care a direct heads up about where things are going.  Then when the
> inevitable complaints do come in at least you've covered your ass :)
>
> Best,
>
> Erik



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