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

Add support for CLICOLOR/CLICOLOR_FORCE/NO_COLOR output controls #7154

Merged
merged 3 commits into from Jun 30, 2020
Merged

Add support for CLICOLOR/CLICOLOR_FORCE/NO_COLOR output controls #7154

merged 3 commits into from Jun 30, 2020

Conversation

kchmck
Copy link
Contributor

@kchmck kchmck commented Jun 5, 2020

Changelog: Feature: Add support for the CLICOLOR/CLICOLOR_FORCE/NO_COLOR output colorization control variables.
Docs: conan-io/docs#1728

  • Refer to the issue that supports this Pull Request.
  • If the issue has missing info, explain the purpose/use case/pain/need that covers this Pull Request.
  • I've read the Contributing guide.
  • I've followed the PEP8 style guides for Python code.
  • I've opened another PR in the Conan docs repo to the develop branch, documenting this one.

Note: By default this PR will skip the slower tests and will use a limited set of python versions. Check here how to increase the testing level by writing some tags in the current PR body text.

This was motivated on my part due to wanting colorized output in Gitlab CI displays. I found CMake could be forced to output colors with CLICOLOR_FORCE=1, and similar to the final comments of #4718, I found Conan could be forced to output colors with the combination of CONAN_COLOR_DISPLAY=1 and PYCHARM_HOSTED=1, resulting in the following at the top of the config:

variables:
  CLICOLOR_FORCE: "1"
  CONAN_COLOR_DISPLAY: "1"
  PYCHARM_HOSTED: "1"

This works because in the current output logic CONAN_COLOR_DISPLAY=1 enables the generation of color codes even through the output is not a tty, and PYCHARM_HOSTED=1 sets up colorama so that it doesn't strip these color codes when it detects that the output is not going to a tty. This setup is a little awkward though, because the CI project otherwise has nothing to do with pycharm. This PR enables the following config to have the same effect:

variables:
  CLICOLOR_FORCE: "1"

It turns out the CLICOLOR_FORCE variable used by CMake has some historical usage on UNIX systems, and there is also a "specification" that describes how CLICOLOR and CLICOLOR_FORCE should be expected to work. Another notable user of this is Ninja.

This PR implements CLICOLOR and CLICOLOR_FORCE alongside the current color control variables. It also adds support for NO_COLOR, which force disables color output, even in cases it would normally be enabled. Some notable users of this include npm and Homebrew.

The first commit adds some tests for the current logic, to help ensure that there is no change in behavior when only the current controls are used. These tests use some mocks over colorama initialization rather than any sort of output testing, as it seems like those sorts of tests could get messy if they need to run on both Linux and Windows. Also AFAICT, how colorama is initialized is what ultimately determines the behavior of colorized output.

In the current implementation, the new variables are checked before the current variables and, if they are used, take precedence. For example, NO_COLOR=1 overrides CONAN_COLOR_DISPLAY=1 & PYCHARM_HOSTED=1, and CLICOLOR_FORCE=1 overrides CONAN_COLOR_DISPLAY=0. Note that the output falls back to the original behavior when NO_COLOR and CLICOLOR are unset and either CLICOLOR_FORCE is unset or CLICOLOR_FORCE=0.

The second commit also extends the tests with various combinations of the current variables and new variables to hopefully cover all of the effective logic branches.

This should provide a solution for #4718 and should also handle the concern in #4718 (comment), as something like NO_COLOR=1 conan --version could be used to disable colors for parsing needs even if running in an environment with a global CLICOLOR_FORCE=1.

@CLAassistant
Copy link

CLAassistant commented Jun 5, 2020

CLA assistant check
All committers have signed the CLA.

@memsharded
Copy link
Member

memsharded commented Jun 7, 2020

The tests are broken, but because something was broken in develop due to last 1.26 release, don't worry about it, we will relaunch it.

@kchmck
Copy link
Contributor Author

kchmck commented Jun 8, 2020

I rebased onto cbc88e0 if that helps any.

kchmck added 2 commits Jun 11, 2020
These are checked in addition to the current color control variables.

The CLICOLOR/CLICOLOR_FORCE variables are implemented according to
https://bixense.com/clicolors/

The NO_COLOR variable is implemented according to
https://no-color.org/

The colorization behavior falls back to the original logic if these
variables are unset or if CLICOLOR_FORCE=0.
Copy link
Contributor

@czoido czoido left a comment

Hi @kchmck, very nice job.
I would like to comment that maybe the tests code could be improved by grouping by the result of the test and also parameterising them to reduce all the repeated code.
Maybe like:

@parameterized.expand([(False, {}), (True, {})...
def test_output_no_color(self, isatty, env):
    with mock.patch("colorama.init") as init:
        with mock.patch("sys.stdout.isatty", return_value=isatty), \
             mock.patch.dict("os.environ", env, clear=True):
            assert not colorama_initialize()
            init.assert_not_called()

def test_output_color...

return False

clicolor_force = get_env("CLICOLOR_FORCE")
if clicolor_force is not None and clicolor_force != "0":
Copy link
Member

@danimtb danimtb Jun 29, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thy not using just get_env() here https://docs.conan.io/en/latest/reference/tools.html#tools-get-env

Suggested change
if clicolor_force is not None and clicolor_force != "0":
if get_env("CLICOLOR_FORCE"):

clicolor = get_env("CLICOLOR")
if clicolor is not None:
if clicolor == "0" or not isatty:
return False
import colorama
colorama.init()
return True
Copy link
Member

@danimtb danimtb Jun 29, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should work as well

Suggested change
clicolor = get_env("CLICOLOR")
if clicolor is not None:
if clicolor == "0" or not isatty:
return False
import colorama
colorama.init()
return True
if not get_env("CLICOLOR", False) or not isatty:
return False
if get_env("CLICOLOR", False);
import colorama
colorama.init()
return True

@czoido czoido merged commit abc1be3 into conan-io:develop Jun 30, 2020
1 of 2 checks passed
@kchmck
Copy link
Contributor Author

kchmck commented Jun 30, 2020

Thanks all!

@kchmck kchmck deleted the feature/color-controls branch Jun 30, 2020
@ytimenkov
Copy link
Contributor

ytimenkov commented Sep 4, 2020

Funny thing: you were so afraid to break customers with my PRs so you finally broke us :( By introducing a lot of new variables with extremely complicated interacton and overriding...

As PR mentiones those variables are used by other tools used by Conan so we set CLICOLOR_FORCE to 1 and this breaks parsing conan output, its --version as it becomes populated with ANSI-sequences.

We explicitly set CONAN_COLOR_DISPLAY=0 when running conan --version and now it no longer works.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants