I’ve contemplated the rewrite of asciinema CLI for several years, but I didn’t have as many good reasons (and time) to justify it in the past. Python served us well for the last 12 years, however, there’s plenty of good reasons to do the Rust rewrite now.
Among other things, the rewrite will (in random order):
minimize runtime dependencies thanks to static binary produced by Rust compiler - e.g. no more need for having Python interpreter installed on a recorded server or in a container
allow easy integration of avt (which is written in Rust) to implement things like conversion to pure text (asciinema convert demo.cast demo.txt), also give asciinema insight into what is actually happening in a terminal during a recording session, potentially enabling many cool features
allow easy integration of tst (which is written in Rust) to implement terminal live streaming (asciinema stream)
allow easy integration of agg (which is written in Rust), potentially as asciinema convert demo.cast demo.gif, so one doesn’t need to install a separate tool to generate a GIF
enable code sharing (where it makes sense) between the CLI and the web player, as the player already uses Rust/WASM
make startup faster - nice to have when automatically recording (“logging”) all shells/terminal tabs to a directory
make me happy as I enjoy working with Rust much more than with Python these days
Current Python codebase is small (~2800 LOC) so it’s not really a big endeavour.
I started working on the rewrite in the develop branch. This will become asciinema CLI 3.0 (I’ll post about the greater plan for 3.0 soon). The original Python implementation (2.x) stays in the main branch for now, and will be kept in an archive branch (python) for the foreseeable future (~forever).
So far I have the asciinema rec, asciinema upload and asciinema auth commands implemented. They seem to work fine, although I tested on Linux only so far.
I looked into portable_pty, among others, when approaching implementation of PTY handling, but decided to implement it using the nix crate, which is more low level but gives me more control. Ended up with asciinema/src/pty.rs at develop · asciinema/asciinema · GitHub , which appears to work well on both Linux and macOS (yet to test it on FreeBSD).
asciinema has never supported Windows natively, and I’m not planning to change that. The previous Python impl worked fine under WSL (from what I’ve heard). We’ll see how the new one fares there.
Out of curiosity, what does portable_pty use on Windows? Is it ConPTY, or something else? If ConPTY, how is its compatibility with control sequences and behaviors commonly seen on UNIX-like systems?
it uses conpty on Windows. I think you won’t really care about the differences in escape sequences used there; it’s actually pretty compatible with commonly used xterm features. I don’t have any windows specific quirks in my asciicast record/replay implementation.
One interesting observation is that conpty will synthesize some initial OSC sequences to set the title to the process name when first spawning a command.
As a long time Windows user it would be very nice to have your software work for us! I understand that you view emulation as an adequate workaround but that doesn’t consider software that only works on Windows. In such cases we simply have no option to record elsewhere.
I’m sure Windows support would be welcomed by many, and I’m willing to reconsider my position, although after 3.0 is released. Then we can look into how to approach this topic
