Invoke==0.12 waits for keypress and gets Broken Pipe when invoking another invoke command through run() #308
Comments
It is the same in Win64 with Python 3.4, except I got the exception using
|
I can kill |
Thanks for the reports! Confirm I can reproduce locally. On poking, noted that the ThreadError/OSError is in the "inner" invoke process ( Also noted that the behavior is improved if Handing So far I'm assuming there's a race condition or other stupidity going on wrt the input mirror loop (which loops until it receives the signal from another thread that the subprocess has exited). Why this is only triggered by nesting is unclear offhand. Will dig. |
Also linking this explicitly to #289 since it came out of that feature. |
Right - it's because Invoke doesn't appear to be a terminal when not in Lines 413 to 447 in 7fe2750 When a real pty is present (again, this is the case if one uses In the case under test, where there is no intended stdin data, this means everything lines up well: that loop runs often, eventually the "is the subprocess done?" test triggers, the loop exits, everything closes up shop, we're done. In the error case, when the input stream doesn't appear to be a terminal (via our custom isatty function) So we end up sitting in tl;dr: we need at least one of the following:
To be continued... |
Examining the state of my local setup, I found that while It should be the same as some other non-Invoke program piped as stdin to Invoke, which is another case I think we have bug reports for (from earlier) as well. Sure enough, So our fixation on "tty-ness" for purposes of how to read from Offhand I am thinking making it "either-or" should suffice (says it's a tty? cool! says it's not a tty, but has a fileno? also cool!) but I need to revisit the reasons why we made it the way it is now (I recall other edge/corner cases being involved). May also involve splitting the method up a bit - some cases we really do care if it's a TTY, IIRC. EDIT: yea, here's all calls to
What I need to do:
|
Minor update, I read Also, FTR, the reason it's always false here, but This is definitely hedging me further towards "we need to separate the questions of TTY-ness and |
So yea, re: previous comment, updating |
Dug a little deeper into our use of
Need to doublecheck to make sure I'm not missing anything, but so far, it does feel like the majority of these actually just care about |
Doublechecked, everything should be listed above now. Re: git history, we did previously rely mostly on I still think that this back & forth is due to the two different questions involved re: Local pty execution jazz vs the concerns about |
Poked a bit re: above:
|
Grump, went ahead and tried flipping everything back to fileno-only testing, but I obviously didn't test enough. Even though we have useful So we probably do still need a mixture of |
Test suites now finding some more quirks I hadn't run into yet, firstly: an integration test that incidentally calls invoke-from-invoke (testing
|
Have everything passing now except for the In most real-world Presumably we simply need to capture this |
This makes me wonder if for "best behavior" we should disable the stdin mirroring IO sleep when stdin fails I also ran into the part where we always echo stdin when Terminals are great fun. |
Tackling the echoing/mirroring (I really need to get better at consistent vocabulary with this shit) first:
|
Hrm. So...we can sorta detect a pipe vs nested situation by testing both stdout and stdin:
But that doesn't really help, because the point of this is to echo a real user's typing back to them. Given how much dumb time I've sunk into this, going with option 3 from previous comment - add an option to control the echoing, have it default to "only if stdin passes isatty and subprocess isn't running in a pty". |
While it didn't take the whole 6 hours since last note, it still took longer than it should have to finished getting that working (mostly due to testing related concerns). I'm bad at computers, folks :( On the plus side we now have yet another Re: the other side note of disabling IO sleep, I am punting on that because of aforementioned difficulty in telling apart a pipe from a nested session (& also just time). Flake8 and Python 3 are satisfied locally; time to see if my integration tests for the greater issue here, works on Travis or not. I bet they don't. If they don't I am probably just going to tell them to skip on Travis, again because JFC I need to wrap this up. |
Incredibly, I was wrong, the tests seem to pass on Travis. Suppose maybe it's a false positive, but meh. Uh...I think this and all its attendant sub-problems are now Fixed Enough, writing a changelog entry and merging. Sorry for the chatter @tuukkamustonen and @presidento ! |
@bitprophet That's some incredible work there. The way you summarize the thought-process into tickets for others to follow and collaborate is exceptional and I'm just happy about the lenghty "chatter". That being said, you lost me halfway through (if not earlier, this stuff is way out of my knowledge) but I do really appreciate the effort you're putting into the project(s)! |
I agree with @tuukkamustonen, thank @bitprophet for the summaries. I have read it as was posted. |
|
On linux, python 2.7 and invoke==0.12:
Works:
Fails:
In 0.11.1 it works just ok.
The use case: While this example doesn't make much sense, in the real world, I'm invoking another invoke commands in sub-directories from a "master" tasks.py.
The text was updated successfully, but these errors were encountered: