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. > 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". Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
