Log file Viewer

[07:16:26] <mgedmin> everything is terrible

[07:18:07] <mgedmin> https://jenkins.gedmin.as/job/mgp2pdf/309/console

[07:18:17] <mgedmin> why do I have `enum` again in my python2.7's site-packages?

[07:18:42] <mgedmin> why does it end up on my pythonpath when I create virtualenvs for python 3.5 but not for 3.4?

[07:19:10] <mgedmin> ooh, cryptography depends on enum34, how nice

[07:19:33] <mgedmin> I decided to placate the InsecurePlatformWarnings spewed by requests and how look where I am

[08:17:56] <Ivo> mgedmin: you hitting that when creating a virtualenv?

[08:18:15] <mgedmin> yes, as you can see in the jenkins console

[08:18:23] <mgedmin> but I can't reproduce this on my laptop!

[08:18:41] <mgedmin> I've upgraded to the latest versions of everything on both machines

[08:18:49] <mgedmin> both run ubuntu

[08:19:24] <Ivo> oh thats that sys.path thing

[08:19:35] <Ivo> yeah need to find something better to do about that

[08:19:35] <mgedmin> yes, but how? why only on 3.5?

[08:20:02] <Ivo> mgedmin: only 3.5 is using some thing, of enum, that enum34 is missing

[08:20:17] <mgedmin> plausible!

[08:20:23] <Ivo> mgedmin: you can see it in stack trace

[08:20:34] <Ivo> 3.5/signal.py gets an enum private attr

[08:20:40] <Ivo> and enum34 doesn't have it

[08:21:00] <Ivo> s/some thing/_convert

[08:28:13] <Ivo> sheeeeeeeet

[08:28:21] <Ivo> how to get to the environment without importing sys or os

[08:30:52] <mgedmin> ouch

[09:01:59] <Ivo> anyone happen to have a python2.5 dagging around on their system?

[09:03:07] <mgedmin> everything from python2.4 until 3.5, except 3.0

[10:45:38] <Ivo> mgedmin: could you try executing a latest virtualenv on python 2.5?

[11:12:54] <Ivo> mgedmin: you could give https://github.com/Ivoz/virtualenv/archive/early-syspath-removal.zip a shot

[11:13:18] <Ivo> for your enum34 issue

[11:29:48] <mgedmin> "latest virtualenv" means "git master"?

[11:30:44] <mgedmin> "this script requires Python 2.6 or greater" -> https://dpaste.de/3Y19

[11:34:27] <mgedmin> yes, that archive fixes the issue

[11:34:35] <mgedmin> assuming I reproduced it correctly

[11:35:30] <mgedmin> https://dpaste.de/q1Ly

[11:36:58] <mgedmin> oh crud my bad :/

[11:37:05] <mgedmin> $ which virtualenv => /usr/bin/virtualenv

[11:38:09] <mgedmin> okay, set $PATH correctly, tried 13.2.0.dev0 from that .zip -> works

[11:39:20] <Ivo> mgedmin: yeah I was thinking about getting rid of that ERROR: None, since it tells you zilch useful stuff

[11:39:40] <Ivo> but I don't have 2.5 so was wondering if there was some chance that 2.5 changed None to something else

[11:40:04] <Ivo> cheers

[11:40:25] <mgedmin> virtualenv dropped support for 2.5 a while ago

[11:41:39] <Ivo> ja

[11:41:53] <mgedmin> jenkins is happy too

[11:42:34] <mgedmin> confirming: pip install virtualenv==13.1.2 --user makes the error go back

[11:42:40] <mgedmin> so it is your fix that made it work

[11:46:17] <mgedmin> https://pypi.python.org/pypi/virtualenv-rewrite/ also works

[12:02:35] <mgedmin> BTW pip on windows.png: http://imgur.com/jYOrwuP

[12:04:20] <dstufft> that shouldn't happen

[12:04:25] <dstufft> what version of pip?

[12:06:01] <dstufft> IIRC colorama is supposed to hide those things

[12:10:35] <mgedmin> I have a daily jenkins job that runs python -m pip install -U pip

[12:10:56] <mgedmin> pip --version says 7.1.2

[12:12:09] <mgedmin> NB: I'm using git bash

[12:12:17] <mgedmin> $TERM is cygwin

[12:13:38] <dstufft> I wonder if that's causing it

[12:13:54] <dstufft> might be throwing off colorama or something

[12:14:09] <ionelmc> well put it on path

[12:15:10] <ionelmc> one of those windows things :)

[12:15:45] <mgedmin> yeah, cmd.exe is fine: http://imgur.com/1KWylEJ

[12:16:32] <mgedmin> it is TERM=cygwin! http://imgur.com/Y53voVu

[12:17:33] <dstufft> https://github.com/tartley/colorama/issues/35

[12:17:35] <mgedmin> I assume colorama is https://github.com/tartley/colorama? (because pypi seems to be down for maintenance)

[12:17:39] <dstufft> maybe we should detect TERM

[16:25:07] <manzo> Hi, is there anything on setuptools 18.3.2 that uses pbr? My setup.py has nothing mentioning pbr, but nevertheless I'm getting into memory leaks that traces to pbr when i run python setup.py test (I'm running python 3.5)

[16:26:27] <ionelmc> manzo: maybe you got that buggy pbr that activates when it shouldn't

[16:27:05] <ionelmc> upgrade it or uninstall

[16:28:45] <carljm> manzo: I don't know much about pbr, but with setuptools entry points it is possible for a package to activate itself simply by being installed, without ever being mentioned.

[16:29:03] <carljm> (that's pretty much the use case for setuptools entry points -- a bad use case if you ask me, but there it is.)

[16:32:05] <manzo> thanks, carljm but I can reproduce this on a empty virtualenv with nothing else installed

[16:32:23] <manzo> so maybe some dependency is installing pbr?

[16:33:44] <manzo> haha mock is using pbr https://github.com/testing-cabal/mock/blob/master/setup.py

[16:35:05] <ionelmc> as if it wasn't bad enough :)

[16:35:56] <ionelmc> quite sad the maintainers are so stubborn https://github.com/testing-cabal/mock/issues/311

[16:45:37] <manzo> https://www.irccloud.com/pastebin/j4Hlvsrq/

[16:45:54] <manzo> looks like that with python 3.5 it has a parse error as well

[16:45:56] <manzo> :/

[19:07:24] <dstufft> manzo: open an issue with pbr is likely the best thing