Pipenv: Refrain from using red color for successful output in terminal

[zedrdave]

Currently, pipenv uses red to output standard virtualenv creation outputs:

Creating a virtualenv for this project…
Pipfile: /app/Pipfile
Using /usr/local/bin/python (3.7.3) to create virtualenv…
⠏ Creating virtual environment...Already using interpreter /usr/local/bin/python
Using base prefix '/usr/local'
New python executable in /root/.local/share/virtualenvs/app-4PlAip0Q/bin/python
Installing setuptools, pip, wheel...
done.

✔ Successfully created virtual environment! 
Virtualenv location: /root/.local/share/virtualenvs/app-4PlAip0Q

In a large terminal log output, this makes it very difficult to quickly scan the log for [absence of] errors.

Could we perhaps use a more subdued color (eg blue, albeit not the dark blue that people complained about), or even the default terminal color, since these aren't particularly critical information to begin with…

[jxltom]

Do you mind append a screenshot for the output? I remember only the path of python and Pipfile are in red.

[zedrdave]

Here you go.
It's only a few lines in red (the rest is then default color), but still not great UX.
Red should only be used for abnormal outputs…

[jxltom]

I think this is in Circle CI which has different output with windows or linux terminals. It doesn't display colors correctly, but this still needs some enhancement for sure.

[zedrdave]

The one above is inside a docker (not using Circle CI, afaik), but I'm still getting quite a bit of red text when running locally on OS X (name of Pipfile and python exec).

[techalchemy]

yeah we do use quite a bit of red, it's definitely something we can consider.

We should reassess the overabundant use of color everywhere most likely

Thanks for the issue! If you have suggestions we are definitely open to them

[omkar-dsd]

crayons.normal() is using the default foreground color, which is resulting in red. Should we use crayons.white() instead? I'll pick it up. :raised_back_of_hand:

[workingjubilee]

No repro on the primary source of red, here. As omkar notes this is from crayons.normal() and on my end that is not a reddish hue:

I bring this up because I would in fact prefer usage of my normal terminal hue for most output. Obviously, there's still a lot of lines using a flavor of red, there, so I still agree with the main point. Over here, crayons.white() is indeed a highlight that is attention-getting without being obnoxious. Terminal emulator is Konsole.

[omkar-dsd]

Ok. Picking this up. Checking for the places where red is being used without proper concern.

[GPHemsley]

yeah we do use quite a bit of red, it's definitely something we can consider.

We should reassess the overabundant use of color everywhere most likely

Probably the first step would be to agree on a set of guidelines for what each color means and when they should be used.

And then perhaps update pipenv/patched/crayons.py with functions for meaning instead of just color.

[zedrdave]

Is there an update on that issue?

Also, I have noticed this seems to crop up mainly inside Docker container logs, where every other pipenv command has some red text, whereas not so much when running locally (on an OSX terminal window). No idea why that is…

[stelios357]

Is the issue still open?

[workingjubilee]

Obviously so. Should it be? I do not know.
As long as it is a point of discussion:

It may be worth thinking about usage of color in terms of accessibility also. I think considering the Web Consortium Accessibility Guidelines and how they might be applied to the terminal would be a good idea. It's also a good idea to avoid red-green contrasts as is done in pipenv, as red-green colorblindness is the most common.

[wadewilliams]

Probably the first step would be to agree on a set of guidelines for what each color means and when they should be used.

Recommended guideline:

Use red for errors only.