-
Notifications
You must be signed in to change notification settings - Fork 35
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
stdout and stderr are non-blocking #444
Comments
It could be behaviour in the py2app stub, but I don't explicitly set nonblocking mode there. I don't get this behaviour with the project in The option |
I'm using Twisted in this app and it's possible that something in there is doing this — although it shouldn't be, that's only supposed to happen with I'll try to create a minimal reproducer. |
OK, this gets even weirder. I definitely narrowed it down to a minimal reproducer and it was definitely not what I thought. The bug is in py2app (or maybe distutils?) but not in anything runtime-related. If you make a shell script that runs This doesn't happen with, e.g. I think my shell (zsh) is resetting the blocking state of the terminal on every interactive prompt, I think, which is why this doesn't happen interactively. |
Weirder still. This affects builds themselves. The output from
but |
This is very weird indeed, but finding the root cause might help fix other build issues. Py2app contains some retry loops for subcommands that fail, and IIRC at least some of them were added due to similar errors. Are you on an M1 based system, or at least use a Python build with arm64 support (such as the 3.10 installers on Python.org)? |
For some reason the ibtool(1) command sets the std* streams to non-blocking when compiling nib files. Add a context manager to reset the blocking status for these streams and use that will all invocations of xcode tools (not just ibtool).
Turns out this is a mis-feature of the ibtools(1) command used to compile NIB/XIB files. The changeset above fixes this and removes an older workaround for broken builds. I'm not closing this issue yet because I'm thinking about creating a branch with a hot fix in the 0.28 release. I'm not comfortable yet about releasing from the tip of the tree, I'm partway through code cleanup and am not 100% sure that a release would be problem free. And finally: Thanks for the reproducer, that made it a lot easier to debug the issue. |
Sigh. For some reason my fixed worked for some time, but working on a back port somehow broke things again. To be continued... |
This should be fixed in py2app 0.28.2 which is on PyPI. |
@ronaldoussoren thank you for fixing this! I independently discovered the |
If you put this code very close to the beginning of your python code in py2app:
and run it in a terminal, you will see
4 4
, indicating that the stdout and stderr streams have been set to non-blocking mode for some reason. This means (among other things) tracebacks will be irritatingly truncated when debugging in this way. It's easy enough to fix—justfor fd in [1, 2]: fcntl.fcntl(fd, fcntl.F_SETFL, fcntl.fcntl(fd, fcntl.F_GETFL) | os.O_NONBLOCK)
—but this is annoying out-of-the-box behavior and very obscure.Is this something that AppKit or LaunchServices are doing on one's behalf, somehow? I don't know how they'd get involved before
NSApplicationMain
when you're just running the app as a binary in the terminal; is it behavior in the py2app stub?The text was updated successfully, but these errors were encountered: