py.test creates an environment that causes colorama to fail

[pytestbot]

Originally reported by: Paul Moore (BitBucket: pmoore, GitHub: pmoore)

---

When running a test file that imports colorama on Windows, the import fails (as far as I can tell, because the Windows standard handle does not point to a proper console)

Here's an example:

>type t.py
from pip.vendor import colorama
>python t.py >a
>type a
>py.test t.py
============================================= test session starts ============================================== platform win32 -- Python 3.3.0 -- pytest-2.4.1
collected 0 items / 1 errors

==================================================== ERRORS ==================================================== ____________________________________________ ERROR collecting t.py _____________________________________________ t.py:1: in <module>
>   from pip.vendor import colorama
pip\__init__.py:10: in <module>
>   from pip.log import logger
pip\log.py:11: in <module>
>   from pip.vendor import colorama
pip\vendor\colorama\__init__.py:1: in <module>
>   from .initialise import init, deinit, reinit
pip\vendor\colorama\initialise.py:4: in <module>
>   from .ansitowin32 import AnsiToWin32
pip\vendor\colorama\ansitowin32.py:11: in <module>
>       winterm = WinTerm()
pip\vendor\colorama\winterm.py:25: in __init__
>       self._default = win32.GetConsoleScreenBufferInfo(win32.STDOUT).wAttributes
pip\vendor\colorama\win32.py:64: in GetConsoleScreenBufferInfo
>           handle, byref(csbi))
E       ctypes.ArgumentError: argument 2: <class 'TypeError'>: expected LP_CONSOLE_SCREEN_BUFFER_INFO instance instead of pointer to CONSOLE_SCREEN_BUFFER_INFO
=========================================== 1 error in 0.74 seconds ============================================ 

This makes the pip test suite fail on Windows, so it is a relatively serious issue for pip.

---

• Bitbucket: https://bitbucket.org/pytest-dev/pytest/issue/365

[pytestbot]

Original comment by Paul Moore (BitBucket: pmoore, GitHub: pmoore):

---

On reflection, I'm not sure if this is a py.test bug or a colorama bug, so I have reported it to both projects. I suspect that maybe colorama should ensure on import that it does not try to initialise itself if the standard output is not suitable. But maybe py.test should also have an option to not mess with stdout for cases like this.

[pytestbot]

Original comment by holger krekel (BitBucket: hpk42, GitHub: hpk42):

---

pytest uses py.io.TerminalWriter() which implements coloring via ctypes call. Not sure how it can be fixed (i didn't add the original code). But i am wondering if the TerminalWriter could just try to initialize colorama itself and use ansi codes (which it does on Linux) and otherwise fallback to the old behaviour.

[pytestbot]

Original comment by holger krekel (BitBucket: hpk42, GitHub: hpk42):

---

I think it's anyway a good idea to rather use colorama and have that project care for proper win32 interactions instead of duplicating the effort. So i went ahead and changed py/pytest to use colorama. this should help with your use case, could you try?

Install it with:

pip install --pre -U -i http://devpi.net/hpk/dev/+simple/ pytest

A subsequent py.test --version should give you pytest-2.4.2.dev1

[pytestbot]

Original comment by Paul Moore (BitBucket: pmoore, GitHub: pmoore):

---

Wow! Amazing response! The updated py.test seems to work fine. It handles my small test case perfectly and seems to run the pip test suite cleanly now as well.

Many thanks for such a quick response. This was causing me real grief, and I wasn't expecting a fix anything like this quickly.

[pytestbot]

Original comment by holger krekel (BitBucket: hpk42, GitHub: hpk42):

---

fix issue365 and depend on a newer py versions which uses colorama
for coloring instead of its own ctypes hacks.

[pytestbot]

Original comment by holger krekel (BitBucket: hpk42, GitHub: hpk42):

---

Paul, may i ask you to install again (in a clean virtualenv) like this:

pip install -U -i http://devpi.net/hpk/dev/+simple/ pytest

and report back if things work? This should get you the pytest-2.4.2 final release candidate which should pull in colorama on windows and use it appropriately.

Note that pip's vendored "colorama" might not be able to detect that there is another "colorama" active already (the pip vendored one is probably imported as a sub package). I've left Donald a note on IRC to discuss how to deal with it. If it is a problem i think pip's test suite should make its colorama available via "sys.modules['colorama'] = pip_vendored_colorama_module" which should prevent a double import. Alternatively, colorama could learn to deal with another instance of itself wrapping a stream already. Doing something on the pytest side related to this issue seems like a hack to me, unfortunately.

[pytestbot]

Original comment by Paul Moore (BitBucket: pmoore, GitHub: pmoore):

---

That works fine.

This is with development pip, which I've just updated to vendor the latest colorama. Last night I was getting failures with development pip because we were vendoring an older version (0.2.5). So yes, I think we need to sort out the possibility of clashes between the vendored colorama and any system one. But I agree, that's a pip issue not a py.test one.