Open Stack

-----Original Message-----
From: Chris Dent <cdent+os at anticdent.org>
Reply: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
Date: March 14, 2016 at 10:23:04
To: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
Subject:  Re: [openstack-dev] [all] Maintaining httplib2 python library

> 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.

So I've done the "merge a 2/3 split codebase into one" a few times before. It's not a trivial amount of work. Doing that kind of work will not lend itself to the project maintainers saying "We think this project should be put to rest." because the maintainers will have just put in a non-trivial amount of work.

I haven't looked through the open pull requests but there were upwards of 10, some of which I would be willing to bet are already conflicting with master and others that will conflict with each other. The owners of those PRs probably won't care to update them so it will fall to the maintainers to fix those if they want to merge them.

Finally there are over 100 open issues. Some of which can be solved for people by moving to requests or urllib3 (that I noticed on the first page, e.g., CIDR notation in proxy environment variables). The project has been unmaintained long enough and should just be put to a tidy rest.

I think the best course forward for a project like httplib2 would be to put it into security fix mode only (for some period of time) and urge people to migrate as soon as they can before that.

> >> [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?

I don't think gabbi or httplib2 is broken. That's not what I'm saying. I think every project deserves to be able to die. I think communities think of the death of a project as some great tragedy. New and better projects will sprout up. Look at what happened with PIL and Pillow. Pillow is a better maintained and far more viable replacement for PIL. I bet PIL still has an impressive amount of downloads to this day regardless of how easy a transition to Pillow should be.

--  
Ian Cordasco