[eropple]

This is technically, and therefore the best kind of, correct, but in practical usage there's Ruby and JRuby and, uh...does it run in IronRuby?

I mean, libsass is a thing, but it's not nearly feature-complete. You end up bolting a Ruby thing into your pipeline somewhere, which is a bit of a drag depending on how you're used to doing things. (For me, I just let Play handle it, but if somebody hadn't made play-sass I probably wouldn't be using Sass at all.)

[gkya]

I am not a designer, and the only place I use sass is a bunch of static blogs, including my primary one. The command I run to compile my sass files is as follows:

  find . -name '*.sass' | onchange -s make css

where onchange is a simple command I've written that watches filesystem for events on files from stdin and runs command when they occur, and make css is simply

  sass --update _sass:dynamic/styles

So long as sass is in the $PATH, I'm good to go. I don't care how my sass files are translated to css files, I only care whether they get translated or not. In the last place I worked, they used guard for compiling less (sth. like sass) files and concatenating them, which was a frightening program with a huge configuration file, written in JSON. For concatenation, I'd do

  find dynamic/styles -name '*.css' | onchange -s cat dynamic/styles/*.css > dynamic/all.css

See, when your abstractions are processes, everything is easy. It's like git, one simply does not need to know if git commit is a shell script or a C program. It is a process, you need to call it, and that's it.

edit: put in absent redirection into the last command line.