On 17 October 2013 21:14, Jim Fulton <j...@zope.com> wrote: > On Wed, Oct 16, 2013 at 11:01 PM, Donald Stufft <don...@stufft.io> wrote: >> So what I would like to do is "remove" these fields. This would consist >> of modifying PyPI to return an error code if they are included and hiding >> the existing data in the UX. It might at a future time also consist of >> removing >> the data from the DB all together. >> >> What do people think? > > IIUC, you're proposing to error on uploads of distributions with these > fields set. This wouldn't effect distributions already uploaded and wouldn't > cause (new) breakage for consumers of those distributions. The only > breakage would be for authors uploading the buggy distributions. These > are the people who could actually address the breakage and who would benefit > from the breakage by finding out that they have a bug in their distributions. > This seems an appropriate form of breakage to me, so +1.
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. 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. 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. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig