[IPython-dev] Screen-like use-case implementation questions

[Erik Tollerud]

I've been thinking about this ever since the qt console appeared, but
it seems like now that zmq has hit master, it might be a good time to
actually look more into implementing this idea. As I see it, the
IPython two-process model is an excellent way to replace a common use
case that is currently (clunkily) only addressed via GNU Screen:

I regularly log into a computer on which a long-running python process
is operating, but on a connection that I can't keep open (typically
sshing into a desktop while I am traveling). Screen has been a
reasonable way to deal with this, as it doesn't care if my ssh
connection drops - the terminal will just connect back up when I came
back later.  But of course it is not ideal as it is not very
adaptable.  An IPython kernel that I can disconnect from and reconnect
to (like the current qtconsole) with the most appropriate frontend for
the occasion is a great answer to this use case...

A few things are preventing this right now though: First, there's no
simple way to manage a kernel in the way needed for this use case -
but this is probably just a matter of subclassing KernelManager to
create a scheme to store simple names that can be used to map onto all
the necessary ZMQ connections and the like.

Crucially, however, there needs to be a way to connect to the kernel
through a terminal-based frontend, so that I can easily ssh in without
needing to go through the qt client, as that would be very slow using
X forwarding.  But as I understand the TerminalInteractiveShell code,
it seems to be implemented separately from the ZMQInteractiveShell.
This says to me that there is no easy way to connect the existing
terminal shell to a ZMQ kernel - is that the case?  Or is there some
way I'm not understanding to connect to a ZMQ shell directly from the
TerminalInteractiveShell?


(Also, a nice but not critical piece would be to use this in a
system-shell like mode a la the pysh profile, as then there would be
no need for screen at all!  In the current master, this doesn't
completely work because calling anything from IPython that requires
stdin doesn't seem to work, as it doesn't seem to get passed from
ipython to the subprocess.  A note in the docs suggests this is
intentional/unfixable, but I vauguely remember some discussion on the
list a while back about passing stdin from frontends into the kernels
- is that possible/implemented?)

-- 
Erik Tollerud