Log file Viewer

[01:17:06] <indygreg> i just tried to build a Python C extension on Windows using the Visual C++ for Python package that was released in September. I had to patch distutils so it could find vcvarsall.bat. is there a better way?

[01:17:28] <_habnabit> indygreg, 2.7?

[01:17:32] <indygreg> 2.7.9

[01:17:42] <indygreg> i looked in the CPython repo and distutils hasn't been touched in ages

[01:17:54] <indygreg> not sure if this was worked around elsewhere

[01:17:59] <_habnabit> indygreg, i was using 2.7.8, but i didn't have any issues building extensions after installing that

[01:18:21] <_habnabit> indygreg, http://www.microsoft.com/en-us/download/details.aspx?id=44266 this is what you downloaded?

[01:18:40] <indygreg> looks right

[01:18:58] <_habnabit> indygreg, this being windows, did you try restarting after installing the msi?

[01:19:29] <indygreg> if you have vs2008 installed, distutils will find that first because it looks at the registry before environment variables: https://hg.python.org/cpython/file/294501835890/Lib/distutils/msvc9compiler.py#l219

[01:19:41] <_habnabit> oh lovely

[01:19:47] <indygreg> i'm starting on a fresh Windows 7 VM

[01:19:48] <_habnabit> so you have vs2008 and this package both installed

[01:19:58] <indygreg> no, just Visual C++ for Python

[01:20:34] <_habnabit> indygreg, anyway i'm still at work and my w7 machine is at home, so i can't look into this at the moment

[01:20:43] <indygreg> the problem is vcvarsall.bat is in a slightly different location in Visual C++ for Python

[01:21:10] <indygreg> https://hg.python.org/cpython/file/294501835890/Lib/distutils/msvc9compiler.py#l257 needs to look in productdir/../ to find it there

[01:21:40] <indygreg> but i think that logic is wrong since it consults the registry before the environment

[01:22:51] <indygreg> also, VS90COMNTOOLS isn't set in the Visual C++ for python environment

[01:22:56] <indygreg> i had to set that manually

[01:23:06] <indygreg> but that wasn't enough to appease the path checking :/

[01:23:14] <_habnabit> indygreg, but seriously, did you restart?

[01:23:44] <indygreg> i'll try restarting

[01:25:24] <indygreg> still no VS90COMNTOOLS environment variable

[01:25:32] <_habnabit> hum okay

[01:26:39] <indygreg> no VS registry keys either

[01:27:18] <indygreg> and I am looking in HKEY_CURRENT_USER (Visual C++ for Python installs itself in ~/AppData, not Program Files

[01:41:55] <indygreg> i'm going to disappear for the night. ping me if you want more info.

[02:34:54] <indygreg> looking over msvc9compiler.py, i suppose i can work around this by setting DISTUTILS_USE_SDK=1

[03:03:39] <indygreg> i went ahead and filed http://bugs.python.org/issue23246

[09:49:28] <ionelmc> indygreg: for the 2.7 VS package you need setuptools>6

[09:50:50] <ionelmc> indygreg: the current state of things from my perspective http://bit.ly/pycompilerwindows

[12:32:02] <ronny> dstufft: is something down? im getting 503's from devpi when i mitigate the cdn

[12:32:17] <ronny> pip install -U pip broke

[12:40:15] <dstufft> ronny: what does "mitigate the cdn" mean

[12:42:56] <ronny> dstufft: an devpi option to go for something thats not on the cdn (cdn deleays caus strange build fails here every now and then)

[12:43:13] <dstufft> there's no way to hit PyPI that's not on the CDN

[12:43:27] <ronny> hm, was there one?

[12:44:31] <dstufft> yea a long time ago

[12:44:40] <dstufft> back before we moved to rackspace

[12:45:06] <ronny> i see

[12:45:15] <ronny> then that option no longer works to begin with

[17:50:34] <indygreg> ionelmc: thanks for the info!

[18:14:09] <raydeo> is pip multiprocess-safe? can I pip install the same package in the same virtualenv from 2 separate processes? there's no pid locking or anything like apt so I'm curious

[18:14:36] <dstufft> raydeo: probably not!

[18:15:01] <raydeo> I saw that there's a lockfile used in the http cache in v6, but I didn't see anything in the install command

[18:15:27] <dstufft> we should probably add something like that, want to create a PR?

[18:15:32] <dstufft> er

[18:15:33] <dstufft> issue I mean

[18:15:37] <dstufft> or a PR would be cool too ;)

[18:15:37] <raydeo> sure

[18:16:12] <raydeo> yeah I'd like to but gotta keep trying to get pyramid 1.6 out and I don't know pip's codebase!

[18:18:16] <dstufft> I know that feeling :)

[18:22:11] <raydeo> well https://github.com/pypa/pip/issues/2361 for posterity

[18:22:19] <raydeo> thanks for the quick answer

[19:42:03] <robodwyer> is there a reliable way to downgrade pip?

[19:42:43] <robodwyer> I'm having trouble filtering out answers related to downgrading *other* packages, and I don't want to just try it and break everything

[19:43:48] <robodwyer> I assume `pip --upgrade pip==1.5.6` should do it?

[19:44:12] <robodwyer> sorry, `pip install --upgrade pip==1.5.6`

[20:00:44] <robodwyer> ok, that command does seem to work. If anyone wants to avoid the incompatible new version of pip, that's the way to go.