On Oct 17, 2013, at 9:53 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
> On 17 October 2013 23:22, Donald Stufft <don...@stufft.io> wrote: >> >> On Oct 17, 2013, at 8:49 AM, Nick Coghlan <ncogh...@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 > people. > >>> 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 in 2005). > >> 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 > distutils". 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. > > Cheers, > Nick. > > > -- > Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
