Log output is no longer coloured following switch to Python entrypoint

[manics]

trafficstars

Bug description

Originally reported in https://github.com/jupyterhub/repo2docker/issues/1030 by @tomyun

Not sure if related, I also noticed texts on the console (mostly) lost colors after this recent change; Jupyter log messages used to have colored headings for warning/info/etc, but they are now all monochrome. Yet some texts are still printed in colors (i.e. Julia banner lost colors, but its prompt still has a color).

Expected behaviour

Actual behaviour

How to reproduce

Your personal set up

---

From @betatim

The fact that colours have stopped working is annoying and we should try and get that fixed. @tomyun do you have any idea why "colours stop working" when you read in and output the output off a process? Do you have time to investigate that a bit?

From @tomyun

2. Regarding color output, I guess it's about the difference between pipe and tty. For example, Julia running on a regular terminal clearly shows it's on TTY.

julia> Sys.stdout
Base.TTY(RawFD(14) open, 0 bytes waiting)

On the other hand, Julia running on an image created by the latest repo2docker has stdout mapped to pipe which is as expected with the recent change.

julia> Sys.stdout
Base.PipeEndpoint(RawFD(12) open, 0 bytes waiting)

It turns out Julia initializes colored stdout for non-TTY only when it's given an explicit option (color=yes, not default auto) that explains my experience.

It's likely Jupyter (and IPython) works in a similar way that they ended up getting a non-color output here. Seems like this kind of issue is not uncommon as Python has a package like ptyprocess.

From @manics

Before we fix the TTY issue we should decide what beahaviour we want.

If you're running repo2docker from the command line with default options it'll output the logs to the console, in which case colour logs makes sense, and doing this through a pty(?) makes sense since in principle someone could provide input via stdin. If it's run as a background container or a Kubernetes pod you wouldn't expect a terminal to be connected so non-colour logs makes sense.

From @betatim

Is it easier to always support colour output? I think that is what repo2docker used to do and that detecting in which scenario we are sounds like a tricky thing to do (and get right).

[manics]

Note that docker has a flag that controls whether a terminal is or isn't attached to the container, which is one way (but certainly not the only way) that applications determine whether or not to tailor output for an interactive user:

$ docker run -t --rm python:3.9 python -c 'import sys; print(sys.stdout.isatty())'
True

$ docker run --rm python:3.9 python -c 'import sys; print(sys.stdout.isatty())'
False

We should check how the old version of repo2docker behaves begfore changing anything.

[tomyun]

That's a good point. FYI, here are results tested with an image created by the latest repo2docker. It has Python 3.8.8.

$ docker run -t --rm cropbox/cropbox:v0.3.0 python -c 'import sys; print(sys.stdout.isatty())'
/srv/conda/envs/notebook/lib/python3.8/subprocess.py:848: RuntimeWarning: line buffering (buffering=1) isn't supported in binary mode, the default buffer size will be used
  self.stdout = io.open(c2pread, 'rb', bufsize)
False

$ docker run --rm cropbox/cropbox:v0.3.0 python -c 'import sys; print(sys.stdout.isatty())'
/srv/conda/envs/notebook/lib/python3.8/subprocess.py:848: RuntimeWarning: line buffering (buffering=1) isn't supported in binary mode, the default buffer size will be used
  self.stdout = io.open(c2pread, 'rb', bufsize)
False