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

unittest: no color if stdout is not a tty #7424

Merged
merged 1 commit into from
Apr 12, 2018

Conversation

jxy
Copy link
Contributor

@jxy jxy commented Mar 27, 2018

No description provided.

@dom96
Copy link
Contributor

dom96 commented Mar 27, 2018

The only thing I'd be concerned about here is if Travis/AppVeyor/etc will stop getting colours because of it. Would be nice to test that.

@jxy
Copy link
Contributor Author

jxy commented Mar 28, 2018

It is a better default to only output ansi color sequences when output on a tty. In this case, I guess the question is how we can specify the color output in spite of the default. Perhaps we can check the value of NIMTEST_NO_COLOR. Or perhaps we should just use NIMTEST_COLOR to avoid a convoluted double negative.

@FedericoCeratto
Copy link
Member

FedericoCeratto commented Mar 29, 2018

The value should have 3 states always / auto / never to be more flexible than a boolean.
It would be also useful to pick a set of colors for bright VS dark background.
Perhaps always-light / always-dark / auto-light / auto-dark / never ?
Extra parameters for testing could go in nim.cfg or a dedicated conf file.

@data-man
Copy link
Contributor

I'm playing with custom compiler's colored output (nimcolors.cfg).
Currently it's looks like:

colors.compiler:on # can be on, off, auto
colors.compiler.truecolor:on # can be on, off, auto

colors.compiler.error.style = ...
colors.compiler.error.fg = ...
colors.compiler.error.bg = ...

colors.compiler.hint.style = ...
colors.compiler.hint.fg = ...
colors.compiler.hint.bg = ...

colors.compiler.normal.style = ...
colors.compiler.normal.fg = ...
colors.compiler.normal.bg = ...

colors.compiler.warning.style = ...
colors.compiler.warning.fg = ...
colors.compiler.warning.bg = ...

Later this configuration file can be extended for other tools.

We accept a new environment variable, NIMTEST_COLOR,
which override the effect of NIMTEST_NO_COLOR.
The environment variable, NIMTEST_COLOR, can be 'never'
or 'always', which set the color output to false or true,
respectively.
@jxy jxy force-pushed the unittest_notty_nocolor branch from 7bc01ab to 9df2ebf Compare March 29, 2018 19:53
@jxy
Copy link
Contributor Author

jxy commented Mar 29, 2018

Now there is the NIMTEST_COLOR, which can be never or always, which changes the default. Any other value have no effect.

I actually prefer no or yes, but I don't have strong opinion about it.

As to nimcolors.cfg, first this is only for unittest (not the compiler), second I feel it is too complicated to add all the configurations for a unittest module. After all, I just want to grep fail.

colorOutput = false
elif colorEnv == "always":
colorOutput = true
elif existsEnv("NIMTEST_NO_COLOR"):
Copy link
Member

Choose a reason for hiding this comment

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

This shouldn't be an 'elif'.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Because NIMTEST_COLOR should override NIMTEST_NO_COLOR, only if NIMTEST_COLOR is not defined in the env, we consider NIMTEST_NO_COLOR.

@@ -185,7 +192,15 @@ proc defaultConsoleFormatter*(): ConsoleOutputFormatter =
# Reading settings
# On a terminal this branch is executed
var envOutLvl = os.getEnv("NIMTEST_OUTPUT_LVL").string
var colorOutput = not existsEnv("NIMTEST_NO_COLOR")
var colorOutput = isatty(stdout)
if existsEnv("NIMTEST_COLOR"):
Copy link
Member

Choose a reason for hiding this comment

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

This existsEnv check is not required, getenv returns "" if it doesn't exist. And yes, I do like that because it simplifies the logic.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

My original thought was that, if NIMTEST_COLOR is defined, even if not what we recognize (neither never nor always), we would ignore NIMTEST_NO_COLOR.

Perhaps you have a better idea of introducing a new env variable and deprecating the old?

@Araq
Copy link
Member

Araq commented Apr 12, 2018

Meh, whatever.

@Araq Araq merged commit f543388 into nim-lang:devel Apr 12, 2018
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.

5 participants