Output streaming doesn't work on briefcase dev

[freakboy3742]

print() (and other stdout content) isn't reflected in the console when running briefcase dev.

To Reproduce
Steps to reproduce the behavior:

1. Run toga tutorial0 with briefcase dev
2. Click the button several times

There's no error, but:

• On Windows and Linux, the output isn't flushed until you quit the app
• On macOS, the output isn't visible at all.

stderr content is printed to the console.

Expected behavior

print() statements should be reflected in the console.

Environment:

• Operating System: Linux, macOS, Windows
• Python version: 3.10
• Software versions:
  • Briefcase: 0.3.10
  • Toga: 0.3.0.dev38

Additional context

Possibly introduced by 390ccb3?

If you disable stream_output=True on the invocation that starts the dev process, console output is restored; however, you lose the contents of stdout in the log file.

This doesn't appear to impact briefcase run, as full apps have very different processes for managing logs.

[mhsmith]

Possibly introduced by 390ccb3?

I'm pretty sure I saw it before that on Windows. Specifically, I was trying to run briefcase dev in an Emacs compilation window, but I found that when exceptions were caught by the main loop, they didn't appear until after the process exited.

[rmartin16]

I actually encountered this when I added stream_output=True to briefcase dev....although, I guess I figured this was previous behavior and added flush=True to the print statements to finish testing...

Taking another look at this...

Initially, I thought this was Rich buffering the output. However, the buffering for Rich's Console.print() appears to be mostly a mechanism for maintaining integrity for multi-threading. When a Console.print() finishes (or when the last concurrent print finishes), the buffer is written to the output and flush is actively invoked for the output IO object. This is true whether the output is stdout or some other IO.

The buffering must be happening before Rich.

When I add -u to the invocation of sys.executable to run the app, the output is no longer buffered. Without stream=True, the stdout for the app's Python process is connected directly to the tty; with stream=True, the stdout is connected to a pipe. Python must be detecting this and as such buffers the output. This also implies that Python is ignoring bufsize=1 to line buffer the output...or maybe that isn't a flag for the spawned process and only applies to the pipes...

This is my best guess anyway.

[richstokes]

Ran into this with the BeeWare tutorial (https://docs.beeware.org/en/latest/tutorial/tutorial-2.html)

Nothing happens when you send a print command (MacOS).

PYTHONUNBUFFERED=1 briefcase dev fixes it

[freakboy3742]

@richstokes Yeah - that's effectively the fix that we've applied in #892. Apologies for the confusion during the BeeWare tutorial.