On 07/27/2014 12:22 AM, Denis Makogon wrote:
суббота, 26 июля 2014 г. пользователь Thomas Goirand написал:
At this point, I gave-up with mechanize. But then, this makes me wonder:
can we continue to use wsgi-intercept if it depends on such a bad Python
module.
If we are to
On Sun, 27 Jul 2014, Thomas Goirand wrote:
I don't think you get it. The question isn't to fix Trove to be
ready for Py3.4, we're very far from that. The question is: how can I
maintain the python-wsgi-intercept package in Debian, when it now
depends on a very bad package in the newer version
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.
On Mon, 28 Jul 2014, Thomas Goirand wrote:
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.
How would you feel about it being optionally available and for the tests
for mechanize
Hi,
Trove is using wsgi-intercept. So it ended in the
global-requirements.txt. It was ok until what's below...
I was trying to fix this bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755315
then I realize that the last version had the fix for Python 3.4. So I
tried upgrading. But doing
This actually is good question. WSGI framework was deprecate at IceHouse
release(as I can recall). So, Trove should migrate to Pecan ReST framework
as soon as possible during Kilo release.
So, for now, the short answer - it's impossible to fix Trove to be ready
for Py3.4 unfortunately.
Best
