I'd like to commend you on building something and putting it out in there in the world, keep doing that! Also the idea of running commands and code from Markdown is obviously awesome. I think you'll find that the folks you get to use this will want a ton more features, like project wide config, interactive stdin, .ENV tooling, passing of variables between inputs and a lot more. That's why we built runme.dev, the kernel is built in Go, please come join our community and contribute.
We've seen that it's not unusual in operations for folks to walk through runbooks running commands that require small (but important) amounts of human input. Runme makes that experience considerably better by utilizing the markdown that's already there and allowing for behavioral configuration (user prompts, process execution, language interpreter etc). But you can also name, and run groups of cells/commands to streamline your workflows.
There are actually many differences. We focus more on operational tasks, and allow cells to contain code from a number of programming languages in addition to python. In fact most folks are using Runme to make executing runbooks full of bash commands a better experience.
Ok, so from the front page I got the impression it was only bash. I'm hitting cloud APIs via python so Jupyter works for that, and I'm using the python to ssh into systems and run bash there. The two missing things from Jupyter are 1. ssh-ing to remote hosts and running shell scripts (we do it with a bunch of code) and 2. running cells concurrently. But python is a hard requirement.
I've just added the currently supported languages you can execute to runme.dev in the features section (Javascript, Typescript, Shell, Lua, Perl, Python and Ruby for now). Also, the Runme CLI (https://github.com/stateful/runme) also supports running cells in parallel with `runme run -all -p`.
We'd be interested to know how we can help Runme satisfy your use cases, join us on Discord! https://discord.gg/runme
I wonder if you'd get some mileage from my https://p3rl.org/Object::Remote module (or at least stealing the ideas therein ;) - it effectively applies https://p3rl.org/App::FatPacker on-demand over the wire so the remote code can use any (pure perl) module you've got installed locally without needing to be able to write to the disk.
(at https://shadow.cat/ we use it to investigate things on new customers' platforms with only an ssh login and a perl core install as requirements, along with as an ad-hoc "I need to run this on lots of machines without being intrusive" tool)
VS Code can attach to VMs via SSH and the notebooks will transparently run on the remote host. Python works out of the box as mentioned. I’m a co-creator of Runme btw.
I'm on the Runme team, and one of the goals of the primary goals of runme is to use a shared markdown parsing engine so that there is consistent behavior between CLI/GH Action and the VS Code Notebook.
Buoyant builds open source, mission critical service mesh software (e.g. https://linkerd.io) that powers the production infra of companies around the world. Our mission is to democratize reliability and security in an increasingly complex system infrastructure landscape, by giving everyone the power to write safe, reliable software--not just the big tech companies.
We are Series A funded with a small engineering team and a modern tech stack (Go, Rust, Scala, React, Kubernetes, etc). We have strong values, a dynamic, diverse team, and awesome investors (Benchmark, SV Angel). Come help us build a company we can be proud of!
