[Distutils] Deprecate and Block requires/provides

[Donald Stufft]

On Oct 17, 2013, at 8:49 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> Except we can't tell if it's a human or a script doing the upload, and
> if it's the latter, we just broke somebody's automated release process
> without anything even remotely approaching adequate justification.

Even if it breaks it, it's for a small number of users, 931 total projects in
2928 releases in the last year have submitted something using the
``requires`` field. Looking through the data for these it appears that most
of them are NOT using it correctly.

I'd be willing to bet money that the people who are using it are just trying
to get dependency information to show up on PyPI, which they can do
now using Wheel + Twine.

It's an attractive nuisance // foot gun, it confuses uses, and by continuing
to allow it we are making packaging more confusing for users.

> 
> PyPI is a trusted service provider: we can nudge people towards better
> ways of doing things, but something has to pose an imminent threat to
> the integrity of the service itself for us to consider breaking
> backwards compatibility.

I'm not sure I agree with this. PyPI isn't versioned so unless we deprecate
and remove things it's going to just get cruftier and cruftier. For instance
An API might end up with 3 or more different concepts of "obsoletes"
because we were unwilling to remove older metadata that is no longer
in use. That is actively making the entire system harder to use.

That's not to say we should just willy nilly remove stuff, but this seems like
a prime candidate for removal as it is a common pain point that i've seen
new users trying to package things stumble on.

> 
> That's why I suggested following the same approach as Donald did for
> reducing the amount of external scanning going on: creating a separate
> list of all the projects still using the deprecated metadata, and
> encouraging users of those projects to get in touch with the
> maintainers.
> 


-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20131017/b7fbed64/attachment.sig>