<div dir="ltr">Hi,<br><br>So maybe if it gets to the point where it gets too be much of a porblem we should just put it on stackforge.<br><br>Regards<br>chuck<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Wed, Nov 20, 2013 at 9:08 PM, Jamie Lennox <span dir="ltr"><<a href="mailto:jamielennox@redhat.com" target="_blank">jamielennox@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Chuck,<br>
<br>
So it is being used to handle stubbing returns from requests and httplib<br>
rather than having to having fake handlers in place in our testing code,<br>
or stubbing out the request library and continually having to update the<br>
arguments being passed to keep the mocks working. From my looking around<br>
it is the best library for this sort of job.<br>
<br>
When i evalutated it for keystoneclient upstream<br>
(<a href="https://github.com/gabrielfalcao/HTTPretty/" target="_blank">https://github.com/gabrielfalcao/HTTPretty/</a> ) was quickly responsive<br>
and had CI tests that seemed to be checking python 3 support. I haven't<br>
seen as much happening recently as there are pull requests upstream for<br>
python 3 fixes that just don't seem to be moving anywhere. The CI for<br>
python 3 was also commented out at some point.<br>
<br>
It also turns out to be a PITA to package correctly. I attempted this<br>
for fedora, and i know there was someone attempting the same for gentoo.<br>
I have a pull request upstream that would at least get the dependencies<br>
under control.<br>
<br>
I do not want to go back to stubbing the request library, or having a<br>
fake client path that is only used in testing. However I have also<br>
noticed it is the cause of at least some of our python 3 problems.<br>
<br>
If there are other libraries out there that can do the same job we<br>
should consider them though i am holding some hope for upstream.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
Jamie<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On Wed, 2013-11-20 at 14:27 -0800, Morgan Fainberg wrote:<br>
> Chuck,<br>
><br>
> The reason to use httpretty is that it handles everything at the<br>
> socket layer, this means if we change out urllib for requests or some<br>
> other transport to make HTTP requests to we don't need to refactor<br>
> every one of the mock/mox subouts to match the exact set of parameters<br>
> to be passed. Httpretty makes managing this significantly easier<br>
> (hence was the reasoning to move towards it). Though, I'm sure Jamie<br>
> Lennox can provide more insight into deeper specifics as he did most<br>
> of the work to convert it.<br>
><br>
> At least the above is my understanding of the reasoning.<br>
><br>
> --Morgan<br>
><br>
> On Wed, Nov 20, 2013 at 2:08 PM, Dolph Mathews <<a href="mailto:dolph.mathews@gmail.com">dolph.mathews@gmail.com</a>> wrote:<br>
> > I don't have a great answer -- do any projects depend on it other than<br>
> > python-keystoneclient? I'm happy to see it removed -- I see the immediate<br>
> > benefit but it's obviously not significant relative to python 3 support.<br>
> ><br>
> > BTW, this exact issue is being tracked here-<br>
> > <a href="https://bugs.launchpad.net/python-keystoneclient/+bug/1249165" target="_blank">https://bugs.launchpad.net/python-keystoneclient/+bug/1249165</a><br>
> ><br>
> ><br>
> ><br>
> ><br>
> > On Wed, Nov 20, 2013 at 3:28 PM, Chuck Short <<a href="mailto:chuck.short@canonical.com">chuck.short@canonical.com</a>><br>
> > wrote:<br>
> >><br>
> >> Hi,<br>
> >><br>
> >> I was wondering for the reason behind the usage httpretty in<br>
> >> python-keystoneclient. It seems to me like a total overkill for a test. It<br>
> >> also has some problems with python3 support that is currently blocking<br>
> >> python3 porting as well.<br>
> >><br>
> >> Regards<br>
> >> chuck<br>
> >><br>
> >> _______________________________________________<br>
> >> OpenStack-dev mailing list<br>
> >> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> >><br>
> ><br>
> ><br>
> ><br>
> > --<br>
> ><br>
> > -Dolph<br>
> ><br>
> > _______________________________________________<br>
> > OpenStack-dev mailing list<br>
> > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> ><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>