Open Stack

Chuck, 

So it is being used to handle stubbing returns from requests and httplib
rather than having to having fake handlers in place in our testing code,
or stubbing out the request library and continually having to update the
arguments being passed to keep the mocks working. From my looking around
it is the best library for this sort of job.

When i evalutated it for keystoneclient upstream
(https://github.com/gabrielfalcao/HTTPretty/ ) was quickly responsive
and had CI tests that seemed to be checking python 3 support. I haven't
seen as much happening recently as there are pull requests upstream for
python 3 fixes that just don't seem to be moving anywhere. The CI for
python 3 was also commented out at some point.

It also turns out to be a PITA to package correctly. I attempted this
for fedora, and i know there was someone attempting the same for gentoo.
I have a pull request upstream that would at least get the dependencies
under control.

I do not want to go back to stubbing the request library, or having a
fake client path that is only used in testing. However I have also
noticed it is the cause of at least some of our python 3 problems.

If there are other libraries out there that can do the same job we
should consider them though i am holding some hope for upstream.


Jamie


On Wed, 2013-11-20 at 14:27 -0800, Morgan Fainberg wrote:
> Chuck,
> 
> The reason to use httpretty is that it handles everything at the
> socket layer, this means if we change out urllib for requests or some
> other transport to make HTTP requests to we don't need to refactor
> every one of the mock/mox subouts to match the exact set of parameters
> to be passed.  Httpretty makes managing this significantly easier
> (hence was the reasoning to move towards it).  Though, I'm sure Jamie
> Lennox can provide more insight into deeper specifics as he did most
> of the work to convert it.
> 
> At least the above is my understanding of the reasoning.
> 
> --Morgan
> 
> On Wed, Nov 20, 2013 at 2:08 PM, Dolph Mathews <dolph.mathews at gmail.com> wrote:
> > I don't have a great answer -- do any projects depend on it other than
> > python-keystoneclient? I'm happy to see it removed -- I see the immediate
> > benefit but it's obviously not significant relative to python 3 support.
> >
> > BTW, this exact issue is being tracked here-
> > https://bugs.launchpad.net/python-keystoneclient/+bug/1249165
> >
> >
> >
> >
> > On Wed, Nov 20, 2013 at 3:28 PM, Chuck Short <chuck.short at canonical.com>
> > wrote:
> >>
> >> Hi,
> >>
> >> I was wondering for the reason behind the usage httpretty in
> >> python-keystoneclient. It seems to me like a total overkill for a test. It
> >> also has some problems with python3 support that is currently blocking
> >> python3 porting as well.
> >>
> >> Regards
> >> chuck
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> >
> >
> > --
> >
> > -Dolph
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev