Red background behind over quota

[plstonge]

When users have a long list of project and nearline spaces, and because the units are sometimes different between the usage and the quota, it is a bit hard to identify any over quota situations. With this change, the background color clearly identifies which quota has been reached or surpassed.

[mboisson]

Mmm, what does it look like with dark terminal ? with bright terminal ? white ? dark ?

[ofisette]

I find it difficult to read on my terminal (dark colour scheme). The issue is that Back is used with the default foreground colour. All colours in a (good) colour scheme should read well against the default background colour, but not all colours are guaranteed to act well as a background colour for the default foreground colour. This can be fixed by using Fore.RED instead. Combined with Bright, it gives the same colour as broken symlinks in ls and gcc error messages, and should be readable in any decent terminal.

Another issue is that you can reach your quota without an entry turning red because a large file write will be rejected if you are close to your quota. (I tested this on Rorqual.) This can be fixed by using if quota_info['space_used_bytes'] / quota_info['space_quota_bytes'] > 0.99 rather than the current test (and similarly for the file count). I would actually suggest to make it 0.95 to give an advance warning.

[plstonge]

On my side, it looks good with a black background and white text:

But it looks bad on a white background with black text. Somehow, the red is darker in this version:

I will try Olivier's suggestions.

Note: to test the color, I have temporarily inverted the operator >=

[plstonge]

This is how it looks with the last revision:

[mboisson]

I wonder if we should also support some sort of non-colorized indications (for colourblind people). Maybe a --nocolor option that replaces those with asterisks ?

[plstonge]

I will try something. The *'s could be there with or without the color, so I will not add another command flag, at first.

[ofisette]

Agreed. With argparse, the typical way to do it would be parser.add_argument('--color', action=argparse.BooleanOptionalAction), which automatically gives you --no-color too.

[plstonge]

Code updated to disable the color on demand, while having asterisks in any case.

[ofisette]

Looks good to me! Works fine on Rorqual. Minor suggested changes.

[ofisette]

LGTM!

[bartoldeman]

lgtm

[obilaniu]

• No-colour support should be mandatory in case the output is redirected to a file, thus asterisks are a good auxiliary indicator.
• The easiest international standard to comply with: http://no-color.org/

[ofisette]

• No-colour support should be mandatory in case the output is redirected to a file, thus asterisks are a good auxiliary indicator.

This would be taken care of by adding colorama.init(), which is indeed missing.

• The easiest international standard to comply with: http://no-color.org/

NO_COLOR support was requested in Colorama already but is not merged yet. tartley/colorama#415

[obilaniu]

Suggestion:

import os +

parser.add_argument("--color", default = os.isatty(1) and not os.getenv("NO_COLOR",""),
                               action  = argparse.BooleanOptionalAction,
                               help    = "Display any over-quota usage in red")

[ofisette]

I suggest to use default=None and pass the value to colorama.init(strip=args.color). This lets Colorama handle TTY detection, NO_COLOR (when implemented), and other checks as needed. Then, there is no need to conditionally define styles.

It is better for such things to be handled in the library and not duplicated in library-using programs.

[ofisette]

colorama.init(strip=args.color)

That should be colorama.init(strip=None if args.color is None else not args.color). Damn logic reversal…