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
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
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-
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.
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
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.comwrote:
Chuck,
So it is being used to handle stubbing returns from requests and httplib
rather
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
Excerpts from Chuck Short's message of 2013-11-20 19:21:14 -0800:
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.
That should be the last resort, when upstream is deemed dead. I'm guessing
upstream would not like to fade away
