Open Stack

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