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 <jamielen...@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.math...@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.sh...@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@lists.openstack.org
> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >>
> > >
> > >
> > >
> > > --
> > >
> > > -Dolph
> > >
> > > _______________________________________________
> > > OpenStack-dev mailing list
> > > OpenStack-dev@lists.openstack.org
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to