Open Stack

On 07/27/2014 09:54 PM, Chris Dent wrote:
> I maintain wsgi-intercept, and I'm happy to remove mechanize if that's
> really necessary. I didn't want it in there but when someone asked for
> it to be back in there was insufficient objection so back in it went.
> 
>     https://github.com/cdent/python3-wsgi-intercept/pull/16
> 
> If it is causing problem, then by all means say so.

Hi,

Thanks for this prompt message. This is very much appreciated over here!

Indeed, that's a big problem for me (as a Debian package maintainer). As
I mentioned, mechanize has numerous issues, one of them is the lack of
Python 3, the other one being so many embedded python modules, most of
them being completely outdated.

> In any case, mechanize shouldn't be _required_, it should just be
> available if you ask for it. If you don't import
> wsgi_intercept.mechanize_intercept mechanize will not be loaded, and if
> you try to do so with Python 3 you'll get an AssertionError and the
> world will crash around you.
> 
> Maybe you aren't looking at the most recent version (0.7.0)?

That's exactly the version which I've been looking at. The thing is,
when I run the unit test with that version, it just bombs on me because
mechanize isn't there.

> If there are issues please report them as bugs on github, they'll
> get fixed:
> 
>     https://github.com/cdent/python3-wsgi-intercept/issues
> 
> If there's a better way to do the optional-ness of mechanize
> (without changing everything else), then please suggest something.

I don't think it's a good idea to have mechanize even optional. That's
an option for a very bad Python module which nobody should be using.

Please let me know if you can release a new version of wsgi-intercept
cleaned from any trace of mechanize, or if you think this can't be done.
If the former, then I'll just wait until you're done so that I can fix
#755315 (which is why I'm adding the Debian bug as Cc).

Thanks again for your reply,
Cheers,

Thomas Goirand (zigo)