On 12 May 2016 at 21:41, Donald Stufft <donald@stufft.io> wrote:
Thus, I would like to remove this feature from PyPI (but not from PEP 503, if other repositories want to continue to support it they are free to). Doing this would allow simplifying code we have in Warehouse anyplace we touch uploaded files (since we almost always end up needing to branch into special behavior for files ending with .asc). It will allow us to reduce the number of concepts in the UI (what is a pgp signature? What do I do with it? etc) without simply hiding a feature (which is likely to cause confusion, why do you support it if you won't show it etc). I think it will also make releasing slightly easier for developers, since I personally know a number of authors on PyPI who don't really believe there is any value in signing their packages on PyPI, but they do it anyways because of a vague notion that they should do it.
I'm a fan of most ideas that lower barriers to migration from the legacy PyPI codebase to Warehouse :) However, I think one of the core points here is that even if GPG keys are removed from the *public* API, we still don't want the migration to break things for folks with automated upload processes that supply signature information - there'll be enough teething problems for the migration without a potential coincident breakage for a couple of thousands projects. That means the trade-off to consider is whether or not dropping this feature will get to the point of being able to deploy Warehouse sooner or not. - if it's already implemented & tested in Warehouse, then leave it alone - you can take it out later, some time *after* the migration - if it's implemented, but not well tested, decide what to do based on whether testing or the below idea seems like less work - if it's not implemented in Warehouse yet, that's when the key requirement becomes "don't break automated signed uploads" If we drop the feature, then my suggestion for a future upload UX is to let uploads with signatures succeed, but implicitly discard the signatures, and *automatically email the maintainer explaining why their uploaded signatures aren't appearing*. Similarly, projects that *had* signatures uploaded should gain a database flag indicating previously uploaded keys have been discarded, such that: 1. The admin page for the project explains why the signatures are gone 2. The affected package maintainers are emailed with a list of projects they maintain from which signatures have been removed The aim here would be to ensure that package maintainers tempted to ask "Where did my package signatures go?" are able to have that question answered *within the context of the service itself*, even if they've never heard of distutils-sig. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia