Open Stack

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
>