https://pantsbuild.org/ logo
Join Slack
Powered by
does `InteractiveProcess` expose a pseudo-terminal...
# development
f
does 
InteractiveProcess
expose a pseudo-terminal to the process being run? (context: I was trying to get the Scala Ammonite repl to run, but when invoked by Pants Ammonite just emits lots of 
sh: /dev/tty: Device not configured
errors)
h
Try with --no-pantsd
w
yep. unfortunately, this is a longstanding issue with how 
pantsd
propagates the TTY: https://github.com/pantsbuild/pants/issues/5223
even across a port from python to rust
probably it has something to do with how we open the TTY, and not fully copying settings from… *handwave
…more modern ticket, but still applies: https://github.com/pantsbuild/pants/issues/9939
added a comment
h
I'd love to see this one fixed in December. How important is it to Scala support?
f
It isn’t important. The Ammonite repl is just really nice to have.
👍 1
and same issue occurs even with 
--no-pantsd
❗ 1
w
…hm. now that is interesting.
f
you can see the issue with my WIP PR https://github.com/pantsbuild/pants/pull/13777 and running: 
./pants --no-pantsd repl --shell=ammonite testprojects/src/jvm::
I can pick a different JVM tool to be the first user of 
JvmToolBase
in any case
it could also be the way that the custom main class I had to write as a wrapper was setting up Ammonite
any way, switched to using junit as the first user of 
JvmToolBase
👍 2
as for 
InteractiveProcess
, maybe we should support setting up a pseudo-terminal for the process invocation?
w
it is one… that’s why most repls already work
f
and then there is no need to try and clone the file descriptors to pass in an existing terminal but rather make a pseudo-terminal only for that invocation
(and then relay the input/output properly)
w
@fast-nail-55400: there is no relaying
f
there is no relaying now but with the insertion of a new pseudo-terminal pair there would have to be is my point
w
see the link in https://github.com/pantsbuild/pants/issues/9939#issuecomment-984862445 : we directly open the client’s TTY from the server, and then no data flows over the nailgun protocol
ah. maybe. but that’s how we started out before moving to direct access to the TTY, and getting any repls working was a challenge.
i do wonder whether it’s possible to 
dup
the relevant handle of the TTY rather than opening one, and whether that would preserve settings
because at a fundamental level, having two open and perfectly proxying should be equivalent to just using one
(more handwaving)
also, fwiw: the reason its beneficial to actually implement TTY access rather than making 
run
or 
repl
the “last command in the run” is that it allows 
--loop
to work for interactive processes… i’m not sure what bazel does here, but i think that 
run
is essentially always “the end of your bazel run”… which is why 
bazel-watcher
ends up forking multiple copies of bazel, and sortof needs to be a wrapper
that doesn’t really apply to 
repl
though… only 
run
, or 
test --debug
👍 1
Open in Slack
PreviousNext
Powered by