On Mon, 14 Mar 2016, Ian Cordasco wrote:
To be transparent, I've also reached out to Joe to help. My main motivation, though, is to bring it to the point where the recommendation is to use something that is not httplib2 eventually. Not every library needs to live on forever.
Makes sense. My preference would be to merge the existing pull request that are sane, do a release, create a single directory and get rid of the weird directory each for 2/3, do another release, and then stick it into hard core maintenance mode with the recommendation you mention. This would allow it to be a healthy thing for the reluctant to move and leave it in a good steady state. Maybe that's overkill though. Maybe it is just better to let it fade out.
[1] If gabbi were to switch it wouldn't be to requests but probably urllib3 because the reason httplib2 was chosen is because it does very little for you and makes few guesses. Requests on the other hand... However there are no immediate plans to make any changes.As a urllib3 maintainer (and requests maintainer) we should chat about what gabbi needs. I'd be happy to contribute reviews for switching to urllib3.
I've just had a poke around at urllib3 and it looks like very little would be required to make it work with gabbi: * adapt the requests intercept in wsgi-intercept to work with urllib3 (it's actually intercepting urllib3 anyway, but the vendored one) * use that intercept in gabbi where needed * replace the gabbi.http.client, the interface is much the same Small enough that I wouldn't except any speedbumps. However, there's no compelling reason to do so (yet) in the sense of "it ain't broke". Or are you saying that you think it is? -- Chris Dent (╯°□°)╯︵┻━┻ http://anticdent.org/ freenode: cdent tw: @anticdent
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
