Open Stack

Looks like there's some recent progress here:

  https://github.com/gabrielfalcao/HTTPretty/pull/124

On Wed, Nov 20, 2013 at 9:30 PM, Morgan Fainberg <m at metacloud.com> wrote:

> I'd be more willing to toss in and help to maintain/fix appropriately
> on StackForge if that is needed.  Though I am very much hoping
> upstream can be used.
>
> Cheers,
> Morgan Fainberg
>
> On Wed, Nov 20, 2013 at 7:21 PM, Chuck Short <chuck.short at canonical.com>
> wrote:
> > Hi,
> >
> > So maybe if it gets to the point where it gets too be much of a porblem
> we
> > should just put it on stackforge.
> >
> > Regards
> > chuck
> >
> >
> > On Wed, Nov 20, 2013 at 9:08 PM, Jamie Lennox <jamielennox at redhat.com>
> > wrote:
> >>
> >> 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
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> 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
> >
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

-Dolph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131204/b4aad7c0/attachment.html>