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...@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.sh...@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 <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 > > > > _______________________________________________ > 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