[Distutils] Deprecate and Block requires/provides
donald at stufft.io
Thu Oct 17 15:59:58 CEST 2013
On Oct 17, 2013, at 9:53 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 17 October 2013 23:22, Donald Stufft <donald at stufft.io> wrote:
>> 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.
> "You're not allowed to upload to PyPI any more until you fix this
> thing that we were previously OK with" is a lousy way to educate them.
>> 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.
> I'm fine with turning it off for projects that don't already use this
> data. I'm *not* fine with breaking something that was working for
>>> 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.
> I'm not opposed to deprecating and removing it. I'm opposed to just
> turning it off cold for projects where it was previously working.
It's been deprecated since 2010 (and the PEP that deprecated it was created
>> 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.
> 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).
> 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
This could be part of the deprecation process, but unless there's a plan
in place to deprecate them I don't know how useful this email would be.
It's a reactive warning to something that confuses people while they are
creating a package. In other words by the time the email goes out they've
already been confused.
Perhaps this needs a PEP to specify a warning period with emails and
then ultimately removal.
> 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