Ideas for remote REPL and remote Snail server?

[orialb]

As I am working a lot with remote files I think being able to use Snail in this situations would be an amazing feature to have (at least for me).
I would be interested in working on such a feature but I'm not really sure where to start (I tried looking a bit at other packages that have remote capabilities but didn't get too far).

Currently I just load the module I'm working on in a local snail REPL and this gives me some code completion capabilities when working on the remote files via TRAMP, which is already nice :) (of course things don't get updated as I make changes on the remote file).

I was wondering if someone has thought about it and maybe have some ideas how can this be achieved with the current repl. Can this be done without implementing a custom elisp REPL ?

[gcv]

Without going down the road of an Elisp REPL, I would try to use SSH tunneling. General approach (totally untested):

• Add a julia-snail-host defcustom to pair with julia-snail-port (make sure it's make-variable-buffer-local). Default to "localhost". You'd configure it the same way as for multiple local REPLs.
• If julia-snail-host is localhost, then just run the (local) julia binary normally (i.e., do what the code does now).
• Otherwise, run julia through SSH and set up a tunnel which would forward local port julia-snail-port to remote port julia-snail-port. I do not know the exact ssh incantation required, but start here: ssh -t -L <julia-snail-port>:localhost:<julia-snail-port> <julia-snail-host> <julia-snail-executable>. (Substitute the variables, obviously.)
• To support the use case of the julia binary being installed someplace outside the remote default shell's path, it might be necessary to mark julia-snail-executable with make-variable-buffer-local just like julia-snail-port and julia-snail-repl-buffer. Not sure. This needs to be tested.

All this assumes SSH is correctly set up with appropriate keys and passwordless login (either with a no-passphrase key (don't do that!) or a running ssh-agent). Since this is a non-trivial system configuration task, Snail should error out nicely if the ssh connection times out or fails.

Since dependencies must be installed remotely, all Pkg definitions must be available on the remote host as well. Activation needs to do the right thing with mapping paths (this may require another local variable which points to the remote project root). For a proof-of-concept, manual setup is fine, but to ship, we need a reasonable story dealing with them. (It might be as simple as providing a function which uses SSH to copy the current Pkg files over to the remote host to some project destination.)

In addition, give some thought about how to support Revise. I suspect a good approach is (1) configuration with .dir-locals.el, (2) editing files with Tramp, and (3) using the SSH tunnel to connect Emacs+Snail to the remote host — but I have not thought through the process at all.

Please post here how it goes. It'll be exciting to support remote Julia development.

[orialb]

Thanks a lot for taking the time to write such a detailed reply, I really appreciate it!
I will try to play with this and update here how it goes.

Since dependencies must be installed remotely, all Pkg definitions must be available on the remote host as well.

Just to clarify the use case I had in mind is that the Julia code is also on the remote machine and the file is being edited via TRAMP. In this case I think it would be reasonable that the user is responsible for making sure that the Pkg environment and dependencies are properly configured on the remote host (as the whole project basically lives on the remote host).

I guess you are thinking about a use case where the code is on the local machine but being sent to a remote Snail REPL/server ?

[gcv]

Yes, that was the intent.

Thinking about it some more: let's only support the Tramp workflow for now.

The entire environment, not to mention all the Snail include(...) hackery, relies on the code being local to the Julia compiler, we'd be stuck synchronizing the code to the remote host anyway.

We can later extend the feature to use rsync or another duplication utility and get better performance than Tramp, but let's hold off on that.

[orialb]

From my initial tests it seems that setting vterm-shell in (a copy of) julia-snail to something like

(format "ssh -t -L localhost:%1$s:localhost:%1$s %2$s %3$s -L %4$s"
                      julia-snail-port
                      julia-snail-host
                      remote-julia-executable
                      julia-snail--remote-server-file)

seems to allow me to start a remote REPL and get code completion + sending lines to buffer.

To get julia-send-top-level-form and friends working I added a buffer local variable julia-snail-temp-dir, which enabled setting the temporary files directory used by julia-snail--send-to-server-via-tmp-file to a remote path (and I also had to make sure a tramp path is handled correctly inside julia-snail--send-to-server-via-tmp).

So it seems like this is going to work.
Next step would be to pack it nicely and do more testing.

[gcv]

Really good ideas on how to implement this better in #36. Snail should provide a way to opt into running the Julia REPL under tmux on the remote host.

[gcv]

At long last, remote REPLs are now part of Snail. Merged in commit 47f1b12. Documentation: https://github.com/gcv/julia-snail#remote-repls