"collecting" messages cluttering Windows CI terminals when --color=yes

[nicoddemus]

Enabling coloring in CI systems such as AppVeyor and Jenkins on Windows by passing --color=yes makes pytest use "console rewriting" for collection reporting, resulting in cluttered collecting messages like this:

============================= test session starts ============================= 
platform win32 -- Python 2.6.6, pytest-2.9.0.dev1, py-1.4.31, pluggy-0.3.1
rootdir: C:\projects\pytest, inifile: tox.ini
collecting 0 itemscollecting 1 itemscollecting 3 itemscollecting 3 itemscollecting 3 itemscollecting 4
 itemscollecting 5 itemscollecting 7 itemscollecting 8 itemscollecting 8 itemscollecting 39 
itemscollecting 39 itemscollecting 58 itemscollecting 58 itemscollecting 63 itemscollecting 63 
itemscollecting 64 itemscollecting 64 itemscollecting 64 itemscollecting 66 itemscollecting 66 
itemscollecting 66 itemscollecting 91 itemscollecting 92 itemscollecting 92 itemscollecting 116 
...

(This is from a branch on my fork to showcase this).

Other than that colors show up fine.

I don't know if that's a problem with Windows in general or just that AppVeyor and Jenkins don't interpret \r output correctly (don't know about other CI systems).

Travis shows colors and handles the "collecting" messages just fine even without needing --color=yes, but I think this is a Travis only feature because the same doesn't seem to happen in drone.io.

I would like to fix this because it really makes using color on Windows CI unpractical, as depending on the number of tests there might be literally pages of "collecting" messages outweigh the benefits of having colors in the first place.

If no one comes with a better solution (perhaps I'm missing some detail), I propose either:

1. Add a new --show-collection-progress which may be used to enable/disable the use of \r to display collection progress. It might even default to False in CI systems.
2. Just disable the collection progress when running in a CI system.

If no one presents a better solution, I like option 2 because it doesn't introduce a new option which might be just noise for most users and fixes the problem out of the box.

[RonnyPfannschmidt]

imho, passing --color=yes clearly states this as acceptable breakable

[RonnyPfannschmidt]

any fix in that manner will be a bolt on, i suggest closing, and working with the introduction of a ui object

which can be more flexible with strategies for reporting to strange systems (i#d love to make a special travis mode as well)

[nicoddemus]

We might disclose some other option then