Related work

[3noch]

I just stumbled on this and I sort of wish I had found it sooner! I just implemented a similar tool at https://github.com/grafted-in/twitch-cli. Mine is not as powerful but perhaps a bit simpler to use. I'm posting here in case there are ideas we can share.

twitch-cli is able to set up many pattern/command patterns and simply relies on you using something like ; or && to run commands in sequence. It uses Glob instead of regex and is therefore a bit simpler but less powerful.

[mitchellwrosen]

Cool! I haven't used sos in a while, but I am mostly responsible for its yucky codebase (originally written by @schell). If there are any features you find lacking we should collaborate and add them!

But yes, it looks like sos is more powerful than twitch-cli at the moment. Regex support allows you to refer to parts of file paths you care about (basename, etc).

Also, right now sos only runs one job at a time, and cleans out the queue if a job fails (so you don't lose its output). A job is killed and restarted if triggered again while running.

If I'm not mistaken, twitch-cli simply spawns threads to run new jobs whenever any corresponding file changes, so you could end up running multiple simultaneous cabal builds or whatnot.

sos certainly isn't perfect... here are a few missing features:

• Better customizability / --help screen, perhaps with example(s)
• Better behavior when both an .sosrc file exists and command-line patterns/commands are given (I forget exactly what happens)
• Maybe you don't want jobs to be preempted but there's currently no way to configure this
• Better logic around debounce timing (it's currently set to some magic number that seems to work most of the time, though occasionally I'll have jobs immediately restart due to my editor making temporary files)
• Perhaps it's due for a complete architectural rewrite to allow for an ncurses/TUI front-end

Cheers, and please let me know if I have glossed over some killer feature of twitch-cli!

[3noch]

Great comparison. To be honest, twitch-cli was about an hour of work, so it's no surprise sos is better! The one thing I do like better about twitch-cli is the ability to set up multiple jobs in the same process. The other features of sos are ones I had planned on adding to twitch-cli, that is the ability to set a semaphore on concurrent processing for each rule, and canceling previous runs when a new change comes along. I personally prefer glob syntax for simple use-cases as it's just easier to write and read. If I need complex parsing of the file path, that could be done in the command itself (likely a script). I wouldn't bother adding RC-file support since it's just as easy to put the entire script invocation in a shell script and run that. So there are many tiny tradeoffs between the two approaches. They are so small that it seems dubious to me to maintain both.

That said, twitch (the library) is very easy to use and may be a way to drastically simplify your code base.

[schell]

I've been absent from sos for a while as my needs have changed. Funny enough I used it yesterday to monitor what files an install process was editing/adding. Maybe we should put together a small wishlist and collaborate.

[mitchellwrosen]

The one thing I do like better about twitch-cli is the ability to set up multiple jobs in the same process.

Ah, that is nice... I think it could be added to sos pretty easily.

Right now, this:

sos -p P1 -c C1 -p P2 -c C2

means: on both pattern P1 and P2, run C1; C2. Instead, we could parse

sos -p P1 C1 C2 -p P2 C3 C4

which means run C1; C2 on pattern P1, and C3; C4; on pattern P2.

I'm not totally sure optparse-applicative can parse a variable number of strings per option, though.

[schell]

I'm totally in favor of incorporating a big parser like attoparsec. It's actually easier IMO, as I always forget the applicative combinators of optparse-applicative.

[schell]

Also - curses would be great!

[3noch]

FYI, I've added configurable debouncing and canceling for existing runs to twitch-cli. I think twitch's simplistic API makes it a different enough approach that it's probably worth leaving the two tools separate. twitch-cli is only one file with 160-some lines and I'd like to keep it really basic. sos is a great option for more complex scenarios. I'll add a reference to it in my docs.

[schell]

Thanks @3noch - I'll accept a pull request with a ref to twitch-cli as well, if you like :)