3 ms·

In Python, twisted.conch provides an ssh transport and a repl implementation which is trivial to hook up in a live system. The ecosystem doesn't really support

by emidln 7y ago

In Python, twisted.conch provides an ssh transport and a repl implementation which is trivial to hook up in a live system. The ecosystem doesn't really support the use case though, so you end up building all tooling from scratch (tmux plus vimux helps a lot here). You also have to structure your code in a somewhat unnatural way for python, like using a dependency injection system to reload and trying to approximate clojure.core/in-ns.

marcosdumay 7y ago
Connecting through ssh to the machine and running a Python debugger there is a much better supported alternative that will give you a REPL capable of querying and modifying a running system. Also, you can avoid dependency injection with monkey patching. Lisp will give you a 2 way compiler, where you can change things and then save them into a source file, AFAIK, Python has nothing like this, but just changing a live system is well supported and common.
- emidln 7y ago
  > Connecting through ssh to the machine and running a Python debugger there is a much better supported alternative that will give you a REPL capable of querying and modifying a running system. ssh into an interpreter gives me perfect control and is reasonably well supported (as far as twisted things go). If you have tmux setup correctly, you can use emacs/vim to eval against your ssh'd python the same way you'd work locally. I've done this for over a decade. It's similar to how I use nrepl+clojure. You can't avoid dependency injection with monkey patching. You have to restart your system on certain changes or reload all of your modules. Further, you need a global reference as an entrypoint to your objects, otherwise you drop in with a debugger/repl and you, what exactly? set a breakpoint for the entire running application? No thanks, not in prod anyway. At least in Clojure, our best practices including using live REPLs for debugging/troubleshooting, but patching only when absolutely necessary. At my last gig, we had tooling setup to allow varying levels of modifications to a particular clojure app with full traffic, limited traffic, or no traffic (depending on what type of environment was required for debugging), and then tooling to auto-apply patches via a combination of zk+ssh+nrepl (only listens on localhost; the hosts and ports were defined in zk) for emergencies (when the system couldn't be restarted safely for some reason). Most of the time, however, the tooling would give you a session to a given app, and when you left the session, would restart the process (safely via load balancing), since it would be problematic to leave systems in indeterminate state.

by emidln 7y ago

marcosdumay 7y ago

Connecting through ssh to the machine and running a Python debugger there is a much better supported alternative that will give you a REPL capable of querying and modifying a running system. Also, you can avoid dependency injection with monkey patching. Lisp will give you a 2 way compiler, where you can change things and then save them into a source file, AFAIK, Python has nothing like this, but just changing a live system is well supported and common.

emidln 7y ago
> Connecting through ssh to the machine and running a Python debugger there is a much better supported alternative that will give you a REPL capable of querying and modifying a running system. ssh into an interpreter gives me perfect control and is reasonably well supported (as far as twisted things go). If you have tmux setup correctly, you can use emacs/vim to eval against your ssh'd python the same way you'd work locally. I've done this for over a decade. It's similar to how I use nrepl+clojure. You can't avoid dependency injection with monkey patching. You have to restart your system on certain changes or reload all of your modules. Further, you need a global reference as an entrypoint to your objects, otherwise you drop in with a debugger/repl and you, what exactly? set a breakpoint for the entire running application? No thanks, not in prod anyway. At least in Clojure, our best practices including using live REPLs for debugging/troubleshooting, but patching only when absolutely necessary. At my last gig, we had tooling setup to allow varying levels of modifications to a particular clojure app with full traffic, limited traffic, or no traffic (depending on what type of environment was required for debugging), and then tooling to auto-apply patches via a combination of zk+ssh+nrepl (only listens on localhost; the hosts and ports were defined in zk) for emergencies (when the system couldn't be restarted safely for some reason). Most of the time, however, the tooling would give you a session to a given app, and when you left the session, would restart the process (safely via load balancing), since it would be problematic to leave systems in indeterminate state.