Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pip needs a way to force all colours off #2449

Closed
nanonyme opened this issue Feb 24, 2015 · 10 comments
Closed

pip needs a way to force all colours off #2449

nanonyme opened this issue Feb 24, 2015 · 10 comments
Labels
auto-locked Outdated issues that have been locked by automation type: feature request Request for a new feature

Comments

@nanonyme
Copy link

According to http://bugs.python.org/issue18553 this code https://github.com/pypa/pip/blob/develop/pip/utils/logging.py#L91-L93 is not completely reliable under Windows as isatty may return True even for non-tty pipes. pip should have an option (eg --no-color) to disable all colour options if it's being called as a subprocess to override automatic checking for whether colouring should be used. Current functionality is fine as default as it's reasonable to expect that most users will be running pip from a real terminal on Windows anyway

@fillest
Copy link

fillest commented Mar 12, 2015

Yes please.
Another use case is build logs in Jenkins web interface - colors don't get rendered and are displayed as plaintext ANSI sequences.

@esc
Copy link
Contributor

esc commented May 9, 2015

Also, on windows using git-bash the ansi escape sequences may not be interpreted correctly.

For example I am seeing:

←[31m

I suspect this is a problem with colorama, but it would be nice to just be able to disable all colors etc.. on command line and via switch.

@asmeurer
Copy link

Would also like to see this. We are having issues with conda list (which calls out to pip list in a subprocess) coloring the terminal on Windows and not uncoloring it.

@DiegoQueiroz
Copy link

This issue is somewhat related to #3771

@lusitania
Copy link

Same thing when building docker images with PyCharm. The ANSI sequences and deflated output make it hard to spot issues quickly.

@bialix
Copy link

bialix commented Oct 18, 2016

+1 - this ansi colors don't play well when running pip on remote machine via fabric.

@nrvale0
Copy link

nrvale0 commented Oct 20, 2016

Related. I would argue this behavior should be like "ls --colors" in that it should have an auto mode which disables coloring when not a tty but also allow for manual override. For instance, in the Jenkins use-case mentioned above, I have the Jenkins ANSI Terminal plugin installed and enabled but I'm currently not able to get colored output because colorize detects that stdout/stderr is not a tty.

@nanonyme
Copy link
Author

Agree with nrvale0. Though I guess auto mode would be current situation, additions would be the always enable and always disable modes.

@xavfernandez xavfernandez added the type: enhancement Improvements to functionality label Nov 14, 2016
oz123 added a commit to oz123/pip that referenced this issue Sep 27, 2017
 This is a fix for issue pypa#2449

 All it does is simply add a global option --no-color

 Internally it switches ColorizedStreamHandler to StreamHandler if
 this flag is detected.
@pradyunsg pradyunsg added type: feature request Request for a new feature and removed type: enhancement Improvements to functionality labels Oct 24, 2017
pradyunsg pushed a commit that referenced this issue Nov 5, 2017
* Add a global option to disable colors

 This is a fix for issue #2449

 All it does is simply add a global option --no-color

 Internally it switches ColorizedStreamHandler to StreamHandler if
 this flag is detected.

* Fix lint errors

 * not sure it makes the code more readable though ...

* Fix typo

* Choose logging class before assigning

 * As requested per review
 * Make the code shorter and easier to follow

* Be polite to followers, add commas

* Add functional test for the --no-color output

* Better detection of windows

* Fix fragile tests - can't trust script --quiet

 * The version found in Travis-CI does not respect this flag
   It added a prefix line and suffix line found if one does not
   add the flag --quiet (script from util-linux 2.26.2).

   As such the out  put is:

     Script started on Fri 27 Oct 2017 07:17:30 AM CEST
     \x1b[31mCannot uninstall requirement noSuchPackage, not installed\x1b[0m\n

     Script done on Fri 27 Oct 2017 07:17:31 AM CEST

  With this change, the test should pass, and is hopefully more stable.

* Simplify testing for color or no-color
@pradyunsg
Copy link
Member

I consider this fixed by #4739.

@esc
Copy link
Contributor

esc commented Nov 5, 2017

Awesome!

kianasun pushed a commit to kianasun/pip that referenced this issue Mar 28, 2018
* Add a global option to disable colors

 This is a fix for issue pypa#2449

 All it does is simply add a global option --no-color

 Internally it switches ColorizedStreamHandler to StreamHandler if
 this flag is detected.

* Fix lint errors

 * not sure it makes the code more readable though ...

* Fix typo

* Choose logging class before assigning

 * As requested per review
 * Make the code shorter and easier to follow

* Be polite to followers, add commas

* Add functional test for the --no-color output

* Better detection of windows

* Fix fragile tests - can't trust script --quiet

 * The version found in Travis-CI does not respect this flag
   It added a prefix line and suffix line found if one does not
   add the flag --quiet (script from util-linux 2.26.2).

   As such the out  put is:

     Script started on Fri 27 Oct 2017 07:17:30 AM CEST
     \x1b[31mCannot uninstall requirement noSuchPackage, not installed\x1b[0m\n

     Script done on Fri 27 Oct 2017 07:17:31 AM CEST

  With this change, the test should pass, and is hopefully more stable.

* Simplify testing for color or no-color
@lock lock bot added the auto-locked Outdated issues that have been locked by automation label Jun 2, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Jun 2, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
auto-locked Outdated issues that have been locked by automation type: feature request Request for a new feature
Projects
None yet
Development

No branches or pull requests

10 participants