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