pmxbot IRC Log Viewer

[08:16:04] <ionelmc> anyone seen anything like this WindowsError: [Error 32] The process cannot access the file because it is being used by another process ?

[08:16:16] <apollo13> yes, often, why?

[08:16:22] <ionelmc> https://ci.appveyor.com/project/ionelmc/python-fields/build/job/m5egvtjknhev59t3

[08:16:26] <ionelmc> how to fix

[08:16:35] <apollo13> don't access the file :)

[08:16:43] <ionelmc> it's raised by pip, see traceback above

[08:17:11] <apollo13> yeah, first step would be to find out what process is accessing that file

[08:17:12] <ionelmc> seems it started to happen recently

[08:17:27] <apollo13> is there another pip process still running in the background or so

[08:17:32] <ionelmc> well yeah, good luck with that, it's a CI service :)

[08:17:53] <apollo13> good luck then indeed :)

[08:18:16] <ionelmc> what process would even use 'c:\\users\\appveyor\\appdata\\local\\temp\\pip-vsni8d-record\\install-record.txt'

[08:18:22] <apollo13> another pip?

[08:18:39] <apollo13> although vnsi8d sounds random per pip invocation?

[08:18:40] <mgedmin> how is it possible for two pips to randomly pick the same random temporary filename?

[08:18:52] <mgedmin> could it be two threads of same pip?

[08:18:57] <ionelmc> but there's a random hash in there, how could any other pip know it

[08:19:32] <apollo13> maybe a virus scanner?

[08:19:54] <ionelmc> good idea

[08:20:05] <apollo13> ionelmc: well, if that tmp code generation had race conditions you might run into something like that, but still seems odd

[08:20:09] <ionelmc> well i suppose i should go pester the appveyor guys now

[08:21:53] <mgedmin> how reproducible is this?

[08:24:19] <ionelmc> mgedmin: all builds fail

[08:25:17] <ionelmc> another example, different project https://ci.appveyor.com/project/ionelmc/python-nameless/build/job/yel3rx80bavg2umj

[08:25:30] <ionelmc> i'm basically just running `pip install tox virtualenv`

[08:26:05] <ionelmc> i have open a support ticket here http://help.appveyor.com/discussions/problems/825-windowserror-error-32-the-process-cannot-access-the-file-because-it-is-being-used-by-another-process

[08:26:15] <ionelmc> don't they have some irc channel or something?

[08:26:33] <mgedmin> ionelmc, if you split that into two commands -- 'pip install tox', and 'pip install virtualenv', does anything change?

[08:26:58] <mgedmin> try to narrow it down: is it pip install of more-than-one package that fails? pip install of a particular package? pip install of any package?

[08:27:22] <mgedmin> if you have a windows system to test on, try to see if it fails there too, or if it's just appveyor

[08:27:47] <mgedmin> hm, *I* have a windows VM with jenkins etc., pip installs seem to work there -- but I haven't tried to pip install tox or virtualenv in a long time

[08:28:07] <mgedmin> might be a new bug introduced in a new pip, or it might be something specific to appveyor

[08:29:43] <ionelmc> trying, cross fingers :-)

[11:21:15] <ionelmc> quite interesting, the second pip install command fails

[11:21:18] <ionelmc> always second

[11:22:32] <mgedmin> hm, so virtualenv's setup.py leaves a process running or something?

[11:23:25] <mgedmin> but no; virtualenv has a univeral wheel on PyPI so there should be no running of setup.py

[11:23:34] <mgedmin> tox otoh has no wheels

[11:23:42] <mgedmin> are wheels at fault? can you try pip install --no-wheel virtualenv?

[11:30:01] <apollo13> I'd inject a command which lists the running processes after the first pip

[11:30:09] <apollo13> that said, second pip call should get another tmp dir?

[11:31:23] <apollo13> same here, would have been my guess too

[11:32:08] <ionelmc> ah well, eventually, for now i like to try something less painful

[11:32:27] <dstufft> are you trying to upgrade pip

[11:32:39] <dstufft> directly or indirectly

[11:32:39] <apollo13> na, he had a get-pip before I think

[11:32:39] <ionelmc> this reminds me of that time i had to dump 100mb strace logs on a file bucket from travis to trace a segfault

[11:32:56] <ionelmc> fun times

[11:33:03] <mgedmin> is there strace for windows?

[11:33:17] <dstufft> upgrading pip via ``pip install`` doesn't work on Windows, you have to do ``python -m pip install`` fwiw

[11:33:27] <dstufft> (fails with that error I think)

[11:33:53] <apollo13> does either tox or venv require a new pip?

[11:36:26] <ionelmc> i use get-pip.py to install pip

[11:37:17] <ionelmc> eg: https://ci.appveyor.com/project/ionelmc/python-fields/build/25/job/7j03pcl0bx6vgr6v#L300

[11:37:58] <ionelmc> `py` doesn't have a wheel so that's not the cause

[11:40:45] <mgedmin> race condition in pip itself? have you already eliminated antivirus scanners as a possible culprit?

[11:41:37] <ionelmc> i filled a support ticket about the AV thing, seems it takes time

[12:25:49] <ionelmc> dstufft: can you point me to the place in the pip code where that 'c:\\users\\appveyor\\appdata\\local\\temp\\pip-8i2cgi-record\\' dir is created ?

[12:26:35] <dstufft> I don't know where such a dir would be created

[12:53:20] <ionelmc> mgedmin: btw, have you seen this http://dev.depeuter.org/xptruss.php ?

[12:54:07] <mgedmin> no

[12:59:09] <ionelmc> well, it appears the best course of action is to write some routine that shows what processes hold pip's temp dir

[12:59:29] <ionelmc> windows programming, yay

[13:00:45] <ionelmc> something like http://stackoverflow.com/a/18028712/23658

[13:00:48] <ionelmc> ew

[13:02:35] <pf_moore> ionelmc - check out http://technet.microsoft.com/en-us/sysinternals/bb896655.aspx

[13:03:27] <ionelmc> interesting, thanks

[13:07:59] <pf_moore> btw, that directory is created in pip/req/req_install.py in install(): temp_location = tempfile.mkdtemp('-record', 'pip-') and removed in the finally block at the end of that function

[13:09:00] <pf_moore> I wonder if the subprocess call for setup.py is returning, but OS cleanup of the process is a tiny bit slow and the record file isn't closed in time.

[13:09:11] <pf_moore> Or it's a virus checker checking the newly created file...

[13:10:19] <pf_moore> Maybe we should make failure to remove the various temp directories we create non-fatal. Or maybe that would end up leaving huge amounts of clutter round. Dunno...

[13:11:19] <ionelmc> pf_moore: yeah, that could work but then it's silent failure treatment, which is bad

[13:13:09] <pf_moore> Agreed, which is why I don't really like it.

[13:13:45] <pf_moore> The big problem is that Unix doesn't have any of these failures (you can delete pretty much anything) so they never show up except on Windows...

[13:24:24] <ionelmc> yay, learning powershell now

[13:26:29] <ionelmc> anyone know powershell here? :\

[13:28:26] <doismellburning> I'm so sorry

[13:30:53] <ionelmc> doismellburning: hahah, is powershell that bad?

[13:41:41] <pf_moore> Yeah, I do (and no it's not "bad", but definitely different...)

[13:45:13] <gauravb7090> hey

[13:45:23] <gauravb7090> I was having problems installing packages using python

[13:45:34] <gauravb7090> it gives me a SSL error

[13:45:34] <ionelmc> ah well, not using ps now

[13:45:36] <ionelmc> but

[13:45:40] <gauravb7090> can anyone help?

[13:45:43] <ionelmc> i have this https://github.com/ionelmc/python-fields/blob/junk/appveyor.yml#L19

[13:45:54] <ionelmc> when run, https://ci.appveyor.com/project/ionelmc/python-fields/build/36/job/03pahhdwuct0pt0y#L342

[13:45:54] <mgedmin> gauravb7090, pastebin your command and the output you get

[13:46:02] <gauravb7090> I am having problems installing packages using pip*

[13:46:03] <ionelmc> No matching handles found. :|

[13:46:04] <gauravb7090> okay

[13:46:58] <gauravb7090> mgedmin: pip install -Uv goslate

[13:47:04] <gauravb7090> error log: https://pbot.rmdir.de/DarzWQjM76NSDWWf3U3pzg

[13:47:04] <ionelmc> pf_moore: seems that whatever helds up that tmpdir is too quick to close the handle

[13:48:54] <gauravb7090> mgedmin: any idea? anything that I should fix?

[13:49:05] <gauravb7090> I'm using the python issued by macports

[13:49:05] <ionelmc> also, the `handle` tool seems slow, at least locally, takes few seconds

[13:49:25] <mgedmin> "error:0D0890A1:asn1 encoding routines:ASN1_verify:unknown message digest algorithm"

[13:49:27] <mgedmin> interesting

[13:50:04] <mgedmin> very similar to https://github.com/pypa/pip/issues/2050

[13:50:42] <gauravb7090> yeah seems so

[13:50:52] <gauravb7090> also It was working just fine about 2 weeks ago

[13:50:53] <mgedmin> you may want to talk to dstufft about this

[13:51:13] <dstufft> right around Sept 11th PyPI upgraded it's certificate

[13:51:20] <dstufft> the new certificate uses a sha256 hash

[13:51:31] <gauravb7090> would updating something do the job?

[13:51:42] <gauravb7090> probably openssl?

[13:51:44] <dstufft> Likely Python or OpenSSL yea

[13:51:53] <dstufft> what OS + Python version are you using

[13:51:55] <gauravb7090> why python?

[13:52:01] <dstufft> X.Y.Z release

[13:52:24] <gauravb7090> OS X 10.8.5 python 2.7 issued by macports

[13:52:24] <dstufft> gauravb7090: on Windows the Python installers bundle OpenSSL

[13:52:38] <dstufft> so it's generally easier to just update Python in that case

[13:52:42] <dstufft> ah

[13:52:45] <gauravb7090> ohh okay

[13:53:23] <dstufft> yea I don't use macports, but updating OpenSSL assuming that macports is linking against whatever openssl it ships (does it ship one?) should do the trick I think

[13:53:57] <ionelmc> now i'm really puzzled

[13:54:11] <ionelmc> what other python projects use appveyor?

[13:54:16] <gauravb7090> dstufft: currently openssl version is 1.0.1i 6th Aug 2014

[13:55:34] <dstufft> gauravb7090: is that what you get with python -c "import ssl; print(ssl.OPENSSL_VERSION)" ?

[13:56:07] <gauravb7090> same

[13:56:27] <pf_moore> ionelmc: I know cookiecutter does, never had a problem like this there.

[13:56:33] <gauravb7090> I even tried updating it

[13:56:41] <gauravb7090> but it still gives the same version

[13:56:48] <ionelmc> pf_moore: yeah but it doens't have recent activity

[13:56:59] <ionelmc> i wanna see if there's something wrong with appveyor

[13:57:04] <ionelmc> or it's just me

[13:57:06] <gauravb7090> dstufft: anything else that you would suggest?

[13:57:37] <pf_moore> Ah. I've been using it a lot recently for some tests - https://ci.appveyor.com/project/pfmoore/blist

[13:57:51] <pf_moore> Wait, I'll push a new build now.

[13:57:57] <dstufft> gauravb7090: moment

[13:58:18] <gauravb7090> dstufft: log: https://pbot.rmdir.de/kyGYtVI7273BIPCSLuQ4KA

[13:59:35] <pf_moore> ionelmc: doh, ignore that it isn't using tox...

[14:00:00] <pf_moore> let me see if I can set up a quick tox setup...

[14:02:52] <dstufft> gauravb7090: python -c "import _hashlib; print(_hashlib.openssl_md_meth_names)"

[14:02:54] <dstufft> what does that give you

[14:03:28] <gauravb7090> dstufft: AttributeError: 'module' object has no attribute 'openssl_md_meth_names'

[14:03:52] <dstufft> bleh

[14:04:12] <dstufft> forgot to look at 2.7

[14:05:12] <gauravb7090> I'm upgrading all the packages side by side using macports to make sure that if something fails because of that it'll get corrected

[14:05:19] <dstufft> hum

[14:05:26] <gauravb7090> I hope that won't be a problem?

[14:05:34] <dstufft> gauravb7090: what's the point release of 2.7 you're using

[14:05:39] <dstufft> 2.7.what?

[14:06:09] <gauravb7090> 2.7.8

[14:06:36] <pf_moore> ionelmc: OK, just submitted https://ci.appveyor.com/project/pfmoore/blist/build/1.0.13 using tox. Let's see what happens :-)

[14:06:52] <pf_moore> (BTW, tox is *so* cool...)

[14:09:53] <dstufft> gauravb7090: python2 -c "import _hashlib; print(dir(_hashlib))"

[14:11:27] <gauravb7090> dstufft: ['__doc__', '__file__', '__name__', '__package__', 'new', 'openssl_md5', 'openssl_sha1']

[14:11:39] <dstufft> so yea

[14:11:53] <dstufft> the openssl that Python is linking against doesn't support sha2

[14:11:57] <ionelmc> pf_moore: i feel better now

[14:11:58] <dstufft> now to sort out why!

[14:12:03] <ionelmc> hehehe

[14:13:29] <gauravb7090> dstufft: is it supported in python3?

[14:13:37] <gauravb7090> I can try selecting that too if you want?

[14:13:39] <dstufft> it's not a python version problem

[14:13:43] <dstufft> it's an OpenSSL problem

[14:14:51] <ionelmc> pf_moore: is there a way to "defer" cleanup on windows?

[14:15:05] <ionelmc> there's something like that in uninstall programs

[14:15:07] <dstufft> gauravb7090: python -c "import _ssl; print(_ssl.__file__)"

[14:15:28] <ionelmc> that could be used in lieu of failure to delete the tmpdir

[14:15:36] <gauravb7090> dstufft: /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_ssl.so

[14:15:55] <gauravb7090> that seems to be an odd path for me

[14:15:59] <dstufft> gauravb7090: otool -L /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_ssl.so

[14:16:12] <ionelmc> anyone here know anyone from appveyor?

[14:16:36] <gauravb7090> dstufft: https://pbot.rmdir.de/8OazX_jAHNlfrqgf_8Rrsg

[14:17:07] <pf_moore> ionelmc: There is, sort of, but AFAIK it's deferred till the next reboot and it's not exposed to Python (so we'd need some platform-specific code, probably involving ctypes, which is sort of icky)

[14:17:09] <dstufft> gauravb7090: k, moment

[14:18:57] <pf_moore> ionelmc: I'd also like to know why my build failed unable to find py>=1 1.4.17 though...

[14:19:49] <ionelmc> pf_moore: because pip failed in the middle, only installed tox, didn't get to installing `py`

[14:21:33] <dstufft> gauravb7090: nm -g /opt/local/lib/libcrypto.1.0.0.dylib | grep sha

[14:23:07] <pf_moore> ionelmc: Oh, yeah, probably. Doh.

[14:23:33] <gauravb7090> dstufft: https://pbot.rmdir.de/pnq5NDdOt7IswrsTbOAlgA

[14:23:35] <tdsmith> looks like a macports build?

[14:24:26] <pf_moore> And yet, I'm getting "Cannot fetch index base URL https://pypi.python.org/simple/" from a local pip command.

[14:24:30] <ionelmc> oh well, maybe they respond on twitter :) https://twitter.com/ionelmc/status/516593069660340224

[14:24:57] <pf_moore> dstufft: any reason why pip might not be able to find PyPI all of a sudden?

[14:25:15] <pf_moore> Worked on Friday... Could the upgrade have messed something up?

[14:25:30] <dstufft> pf_moore: lots of reasons! need a -vvv for more info

[14:25:58] <dstufft> gauravb7090: So your OpenSSL has sha2, but your Python doesn't see that fact, you might try recompiling python against openssl, maybe they added it recently

[14:26:02] <pf_moore> log to follow :-)

[14:26:38] <gauravb7090> dstufft:how should I do that? Can you please help?

[14:27:41] <dstufft> gauravb7090: I don't use macports, http://mac-os-forge.2317878.n4.nabble.com/How-do-I-recompile-one-port-td116559.html has some stuff though?

[14:27:43] <ionelmc> pf_moore: i know what to do!!!

[14:28:00] <ionelmc> use easy_install *evil grin*

[14:28:23] <dstufft> gauravb7090: or http://ewen.mcneill.gen.nz/blog/entry/2012-06-04-macports-rebuilding-broken-port/ ?

[14:28:26] <pf_moore> dstufft: https://dpaste.de/g9HY

[14:29:06] <pf_moore> But it looks like I'm running on a dev version of pip (must have patched virtualenv at some point) - let me retry with the release version too

[14:29:35] <dstufft> pf_moore: urllib3 might have broken on windows

[14:33:40] <pf_moore> dstufft: yeah, looks like it. release version is working. We should probably add appveyor testing to pip (long time since I checked if the tests succeed on Windows, though...)

[14:33:53] <pf_moore> OK, for now I'll switch back to the release version

[14:34:01] <dstufft> it's not like anyone actually uses Windows!

[14:34:03] <dstufft> :|

[14:34:21] <dstufft> petition to make everyone use the same OS

[14:35:01] <pf_moore> yeah, everyone onto Windows then ;-)

[14:35:45] <pf_moore> dstufft: Is pip still using develop branch atm?

[14:35:54] <dstufft> pf_moore: yea

[14:36:20] <dstufft> pf_moore: I would not complain too much if everyone in the world used Windows for everything if it meant I never had to think about cross platform ever again

[14:36:24] <dstufft> (Too much)

[14:36:39] <pf_moore> I'm sure windows could find you other things to complain about ;-)

[14:36:41] <dstufft> pf_moore: I see the problem

[14:37:56] <dstufft> pf_moore: not a windows problem!

[14:38:46] <pf_moore> Cool (well, not really, but...)

[14:41:52] <ionelmc> programming with javascript and html is like herding cats

[14:53:41] <gauravb7090> dstufft: hey I updated the openssl using the same but it still gives me the same output for python2 -c "import _hashlib; print(dir(_hashlib))"

[14:53:49] <gauravb7090> i.e. ['__doc__', '__file__', '__name__', '__package__', 'new', 'openssl_md5', 'openssl_sha1']

[14:53:57] <gauravb7090> still no support for sha2

[14:55:00] <gauravb7090> dstufft: any idea why?

[14:55:53] <dstufft> gauravb7090: I'm not sure :(

[14:56:02] <dstufft> sounds like a macports bug though?

[14:56:11] <gauravb7090> not really

[14:56:16] <gauravb7090> everything compiled fine

[14:56:25] <gauravb7090> is there a manual way to link?

[14:56:29] <pf_moore> dstufft: Just tried running the test suite on Windows. Got https://dpaste.de/Np7K

[14:56:31] <dstufft> Not that i'm aware of

[14:56:44] <pf_moore> Any ideas? "Internal error" sounds scary...

[14:57:00] <gauravb7090> dstufft: how does the linking take place?

[14:57:35] <dstufft> gauravb7090: it happened when macports ran the make file for Python

[14:57:49] <gauravb7090> makefile for python?

[14:58:12] <dstufft> ya

[14:58:13] <dstufft> pf_moore: https://github.com/pypa/pip/blob/develop/tests/conftest.py#L20-L37

[14:58:18] <gauravb7090> dstufft: the link that you sent me had no relation in regard to makefile!

[14:58:20] <gauravb7090> http://ewen.mcneill.gen.nz/blog/entry/2012-06-04-macports-rebuilding-broken-port/

[14:58:32] <dstufft> module_path must be something different on windows

[14:58:40] <gauravb7090> it shows the steps to recompile/upgrade a port

[14:58:45] <dstufft> the port runs the makefile

[14:58:54] <gauravb7090> force upgrade rather*

[14:58:57] <pf_moore> dstufft: Ooh, cool. I never thought it'd be our code. Will look into it...

[14:59:54] <gauravb7090> can I not use an older version of pip? or something of that sort?

[15:00:17] <gauravb7090> I needed some packages like goslate etc

[15:01:25] <pf_moore> dstufft: bet it's backslashes...

[15:02:02] <pf_moore> dstufft: yep, easy fix then :-)

[15:02:24] <dstufft> gauravb7090: you can use pip 1.2 which didn't verify TLS certificates, or you can upgrade to the dev version which offers a flag to disable TLS verification

[15:02:55] <gauravb7090> how can I upgrade to the dev version?

[15:08:30] <dstufft> gauravb7090: pip install git+https://github.com/pypa/pip.git@develop#egg=pip

[15:08:41] <dstufft> pf_moore: https://github.com/pypa/pip/pull/2074 should fix the ssl thing you were getting

[15:09:02] <dstufft> particularly the setup.py change

[15:12:57] <dstufft> pf_moore: Python lulls me into a false sense of security by making Windows accept the / slash sometimes, but not others :| (Or maybe that's Windows fault, i dunno!)

[15:13:55] <pf_moore> dstufft: re the fix, thanks, I'll see if I can give it a try, re backslashes, I know what you mean.

[15:14:31] <pf_moore> Just running the tests on Windows now. Lots of failures, who knows which ones matter. Some amusement for the next few days, I guess.

[15:14:51] <pf_moore> If I can get things in a sane state, I'll add appveyor testing to keep things good.

[15:17:12] <dstufft> pf_moore: does appveyor support github's commit status API (in particular, the multiple status support) and if so, does it also support the concept of "allowed failures"?

[15:17:59] <gauravb7090> dstufft: the git seems to get stuck at some point

[15:18:01] <gauravb7090> no output

[15:22:08] <pf_moore> dstufft: tbh, I don't know, that's more advanced than I've ever used. Would we not just skip tests using pytest skipif, if needed?

[15:24:08] <dstufft> pf_moore: well I specifically meant get appveyor running tests, but allow the whole build to fail so that people who don't have windows boxes can maybe start fixing some of the failing tests

[15:24:28] <dstufft> I'm hesitant to add skipif's, because in my experience they get added as a "temporary" thing, and then never get removed

[15:25:33] <Red_temp> I've been looking over the pypa/pip repo for this issue (I just hit it): https://mail.python.org/pipermail/distutils-sig/2013-August/022528.html and can't find it

[15:26:00] <Red_temp> would that be the right place to submit a bug?

[15:26:42] <pf_moore> dstufft: Ah, I see. Agreed regarding skipifs. At a pinch, we can probably just get appveyor set up to run the tests, but not report success/failure back at all. People can check the build page directly (not ideal, but a start)

[15:26:48] <pf_moore> Leave it with me and I'll see.

[15:27:47] <pf_moore> (BTW, I love the one skipped test in test_install. Makes the output go "FFs". Childish of me, I know :-))

[15:41:08] <tomprince> dstufft: Does github now display mulitple statuses?

[15:41:50] <dstufft> tomprince: yes-ish, it's opt in though

[15:41:51] <dstufft> https://developer.github.com/changes/2014-03-27-combined-status-api/

[15:43:17] <tomprince> Last I tried, it only displayed the most recent status in the UI, even if there were multiple contexts.

[15:43:35] <tomprince> So a failed test run, followed by a succesful docs run would look like success.

[15:46:40] <dstufft> oh

[15:46:45] <dstufft> I've never actually used it

[15:49:54] <pf_moore> There's also http://help.appveyor.com/discussions/kb/4-show-multiple-statuses-in-github-pull-requests

[15:50:22] <pf_moore> Which I haven't used either...

[15:50:58] <dstufft> the non lazy version is to just setup our own damn ci

[15:51:12] <dstufft> but :lazy:

[17:03:01] <pf_moore> dstufft: do you know where I find the config that causes the travis build status to be shown on pip's github pages?

[17:03:31] <dstufft> there's no config for it, travis just knows it because it's wired into github

[17:03:36] <dstufft> it speaks the API and such

[17:05:28] <pf_moore> pff, that's a shame. I need to work out how to make appveyor do the same. I think I need a webhook setting in appveyor somehow, but I don't know how. Oh, well, off to the docs :-)

[17:41:37] <pf_moore> dstufft: actually, appveyor may be a non-starter for pip - I just ran the tests on Windows for 1 version of Python and they took 45 minutes. Appveyor limits jobs to 30 minutes each...

[17:41:59] <pf_moore> I have no view as to why the tests take under 5 minutes on travis compared to that 45 mins...

[17:42:06] <dstufft> how are you running them?

[17:42:16] <pf_moore> tox -e py34

[17:43:02] <dstufft> https://github.com/pypa/pip/blob/develop/.travis/run.sh

[17:46:51] <dstufft> pf_moore: ^

[17:48:56] <pf_moore> ah, ta. didn't realise I pytest-xdist didn't happen automatically...

[17:49:24] <pf_moore> (Although the 3.2 run on travis still only took 17 mins, so Windows is still slower. Subprocess creation overhead, I guess

[17:52:38] <nanonyme> Well, Windows doesn't have CoW process creation

[17:54:33] <buck1> isomorphismes: looks to me like you have a module named urllib that's overriding the stdlib

[17:54:39] <buck1> in a script: import urllib; print urllib

[17:55:32] <nanonyme> Oh, I hadn't realized the repr would have the path

[17:55:36] <nanonyme> Nice to know

[17:57:17] <dstufft> pf_moore: I would feel free to remove 3.2 from Windows

[17:57:30] <dstufft> it's unlikely to have a problem that's Windows specific and only on 3.2 I think

[17:57:41] <dstufft> if it takes too long for appveyor to do it

[17:58:12] <nanonyme> Out of curiosity, are newer versions of Python any faster on Windows for that?

[18:00:04] <pf_moore> nanonyme: I'm just running the tests against 3.4, so no real data to compare

[18:07:20] <dstufft> 3.2 is super slow because we can't use xdist for it

[18:07:25] <dstufft> because it gets wierd errors

[18:16:07] <gauravb7090> dstufft: my python has the sha2

[18:16:34] <gauravb7090> you used python2 that might be a reason for the non availability of sha2

[18:17:06] <gauravb7090> dstufft: https://pbot.rmdir.de/0w3dKkFlGq4WQDOtiizkuQ

[18:32:52] <pf_moore> dstufft: "tox -e py34 -- -m integration -n 8" still no good at 38 minutes, but -m unit -n 8 only 20 seconds

[18:33:04] <pf_moore> May have to stick to unit tests only, at least for now

[18:33:46] <pf_moore> It's all the subprocess calls (particularly git, which spawns reams of further subprocesses) in the integration tests, I guess

[19:54:35] <ionelmc> dstufft: what's xdist?

[19:55:01] <dstufft> ionelmc: pytest-xdist, it's a plugin for pytest that will spin up multiple processes and run tests in parallel

[19:55:13] <ionelmc> aaa

Log file Viewer

Help | Karma | Search:

#pypa logs for Monday the 29th of September, 2014