[FEATURE] Update console color output to match the new color customization support in buildkit

[spkane]

Description

buildkit output colors can now be configured (BUILDKIT_COLORS) or completely disabled (NO_COLOR) via environment variables. This has been merged into the currently released versions of buildkit and docker buildx, and will show up in docker build as soon as Docker CLI v22.06.0. ships.

See: moby/buildkit#2954

It would be really nice to implement the same support into this plugin (and other core docker plugins that output to the console).

The current dark blue is tough to read on a dark background.

For buildkit, the env var looks something like this:

BUILDKIT_COLORS=run=green:warning=yellow:error=red:cancel=cyan

It probably makes sense to support a DOCKER_COLORS env var which is read first by a plugin and then can be overridden by a more specific one if that is set (as in the BUILDKIT case).

It is probably worth putting all this logic into a library that all these plugins can use, but that could be done as a later re-factor as well.

This is an example of what the output looks like from docker buildx, when this variable is used:

Additional information you deem important (e.g. issue happens only occasionally):

Having constant and readable output is pretty important when pairing, mobbing, teaching etc, so making this configurable is pretty useful and avoids forcing people to change their terminal colors, just so the output can be read easily.

Output of docker compose version:

Docker Compose version v2.10.2-13-ge7b488bb

Additional environment details:

• I built the compose plugin from the v2 to make sure there wasn't any unreleased code that addressed this.

[davebarkerxyz]

+1

Being able to disable the colours using an environment variable would be a really useful improvement. The colours are currently unreadable on my light terminal, and having to specify ‘—no-color’ on every invocation is cumbersome.

[milas]

Based on moby/buildkit#2954 (comment), this will likely need to wait until BuildKit v0.11 before support can be added to Compose.

[spkane]

@milas This change has actually already been shipped in buildkit and pulled into buildx v0.9.0 (https://github.com/docker/buildx/releases/tag/v0.9.0) and is now available in the current Docker Desktop release 4.12.0 (https://docs.docker.com/desktop/release-notes/#docker-desktop-4120).

When the Docker CLI v22.06.0 ships (there is a beta at the moment), docker build will also include this, due to the work in this issue: docker/cli#3314

Adding matching functionality for the docker compose output should make it possible to have most of the common/important output that uses the newer style look the same.

[milas]

Yes, the versioning + dependency situation is a bit complex 😅

Compose depends upon moby/moby + docker/cli as well as moby/buildkit + docker/buildx.

Once we've got appropriate stable versions of all those available and pulled into Compose, this should Just Work ™️

Sneak peek:

[spkane]

Makes sense, but what about the rest of the output from compose ?

The intention here was to suggest that all of the compose plugin output should be updated in a similar fashion so that setting something like COMPOSE_COLORS would do the same thing here, for things other than the build.

In the long run, I could see a higher level env var, called DOCKER_COLORS which is read in first by all these plugins, etc., and then could be overridden by the more specific env vars if desired, and that most of this output color logic is actually in a library somewhere that all these plugins can use.

[spkane]

@milas Should I create another issue that more specifically targets the normal compose output versus the buildkit output? That was really my intention initially, but I can see why it was potentially misleading.

[ndeloof]

AFAICT this is already supported with latest codebase:

https://asciinema.org/a/oJ5LmjJViKmx6COQTPEOTsTzP

[spkane]

@ndeloof This issue is about making ALL the output from the compose plugin, to support colorization. This ONLY works currently when compose is using buildkit, it does not work for anything specific to docker compose like docker compose up, etc.

This is why the description was suggesting that it might make sense to support a more generic DOCKER_COLORS env var that sets the colors used for output for any code/plugin that supports it.

This is an example of the plugin using the default dark blue, which is almost unreadable with a dark background.

[ndeloof]

I agree it would be nice to have DOCKER_COLORS to apply to all docker commands.
It would then require moby/buildkit#2954 to be an exported codebase in docker/cli (or a dedicated library?) so all plugins can rely on it. Being non-exported codebase in buildkit and dedicated to buildx needs makes it hard to adopt without a mass code duplication and risks for future inconsistencies. Also always has been a mystery to me buildkit includes console formatting logic and this is not buildx role to do this

[Tux]

It would be even nicer if the default color scheme would default to light mode instead of cusing light gray on white or something similar when not in dark mode so I can read neither question nor answer. Ultimately annoying.

Though dark mode may appeal to many, it also does not appeal to many. Please consider!
Better to have no colors at all than to make feedback completely useless as one cannot read it

(a light-mode user who uninstalls most utilities that only support dark mode as these are making my eyes utterly tired)

[ndeloof]

@Tux this is not really a "dark mode" choice, just legacy terminals used white (or green) on black background, so the default coloring scheme. There's unfortunately no portable way to guess terminal colors to adjust to your local settings.

[Tux]

What should I then set to be able to read the feedback and questions when I have light-background terminals?

[ndeloof]

not configurable yet, see #9818 (comment)