https://pantsbuild.org/ logo
Join Slack
Powered by
This would be a really useful case to toggle foreg...
# development
w
This would be a really useful case to toggle foreground on the process to stream pytest output.
👍 1
h
Let's make sure that we talk about this case when we meet on Thursday
I think this is gonna tie pretty closely to making the v2 UI work well, which is the next chunk of work we (at toolchain) want to prioritize
w
hm... i think that this is might actually be in conflict with making the v2 UI work well. while you are streaming output, you cannot trivially have a UI
h
part of what we want the v2 UI to do is handle streaming input from an ExecuteProcessRequest while also not breaking if other things are sent to it, right?
w
but thinking about it holistically, and figuring out who we might be able to continue to render a UI while streaming output from one test would be useful.
h
my understanding is that ideally, the v2 UI can handle input from arbitrary sources
w
yes. but my assumption has been that while the process is running, it has exclusive access to the Console... which would mean the UI could not render.
h
and will make sure that whatever gets output to the console is clean and sensible
w
that is not possible for "tty-aware" things like repls, and some binaries
...without creating .... synthetic TTYs? i shouldn't say it's not possible. maybe it's actually easy. unknown.
h
right, that's part of the reason for the new 
InteractiveRunner
thing that I just added in the PR
but in this case, where we want test output from an EPR to get logged, we don't have to worry about interactivity
we do have to worry about interactivity in the case you were concerned about where we want to expose a pydb repl in the test
but I think that's going to require basically a new rule
w
if we have multiple interactive APIs, maybe, yea. but that goes to what i was saying about what's easy vs hard.
basically, need both streaming-but-not-interactive (which can have a UI) and interactive (which probably can't have a UI, unless synthetic TTYs...? maybe a thing?)
h
I'm not quite sure what you're imgaining when you say "synthetic TTY"
w
basically, `repl`s and things like `sudo`/`vim/emacs`, and etc want to directly access a TTY and control it
i don't have a great understanding of it, but i think that you can think of tools like 
tmux
or 
screen
as creating and managing a bunch of TTYs
...which processes can then interact with.
maybe there is a rust crate that makes this trivial? that would be amazing.
h
maybe
I'm not sure what we'd gain out of reimplementing part of tmux in pants though
we can't use EPR for anything that we expect to stop and wait for user input, unless we build the ability to fake that user input at least sometimes
which maybe we want to do for some things?
w
Right. Which is why I suggested that we would need to have two APIs if we wanted both interactive and streaming-with-a-ui
h
yeah, that makes sense to me. my open PR is an attempt at the former
w
Re: EPR: we can. That was what was suggested by foreground/exclusivity
h
and the latter is something that we could do by modifying EPR and/or the Console
Open in Slack
PreviousNext
Powered by