[Comment removed by author]
The ideal is a binary that does not even require the language installed. Go really wins here.
I strongly agree! I think this is one of the best things Go has going for it. I wish Rust made static linking and cross compilation as easy as Go does.
If I found a CLI app that I wanted to use and it required Docker, I would probably re-write it.
I definitely did consider a re-write. In this case, I was starting with not so much a monolithic CLI app as much as a collection of Ruby, Node.js, and native libraries and tools that were being driven from a complex Rakefile. Switching to a GLI-based Ruby CLI app front end cleaned up the user interface significantly, but I still had the hard problem of providing the same behavior across different machines. More portable libraries that purported to support the same functionality repeatedly fell short of expectations (e.g. libsass). I opted to use this Docker image technique as a means of incremental improvement. In the future if I were to find, for example, a set of Go libraries that can exactly mimic the functionality of the current app, it would now not be hard to swap out the messy internals.
A rewrite often sounds like the best idea, but when users already depend on the particulars of an existing implementation, there may be a lot of details that turn out to make rewrites more difficult than one might expect.
This is a crude hack that papers over serious issues with the build.
I mostly agree, and I think the fact that this was a practical way forward is telling about the tunnel vision language communities can have when it comes to software distribution.
I’d be curious to see where you think libsass falls short. I’ve been considering using it to avoid a Ruby tool chain, but it does seem to lag quite a lot.
I wish I could provide more details, but we did not exhaustively document the issues we encountered at the time. If I recall correctly, one of the issues was that Susy, didn’t work with libsass, though a quick Google search indicates that may have changed since we last tried. In general though, we got a sense that the switch was going to place an undue burden on our design team to remove dependencies on several compass extensions they were used to relying on.
Things may be better now, and I should probably re-evaluate libsass for use on this project in the future.
This is where nix & guix shine. If you require the docker daemon to be installed and running, just make it a nix-daemon instead and avoid this mess.
I love the ideas behind nix and guix, but my experience trying to use nix on OS X hasn’t been great yet. A lot of the packages I wanted to use seemed to only work on Linux (maybe because of libc dependencies or something?), and things took a very long time to compile because there weren’t cached builds for my platform. It’s definitely not something I’d want our designers to have to wrestle with at this point.
As I said above, a statically linked binary (e.g. in Go) would probably be the ideal here (especially if I also had the time to give it a nice GUI), but short of that, Docker isn’t that awful of a dependency. Docker Toolbox has a pretty nice installer and they’re incentivized to maintain a certain degree of usability.
Things in the nix/guix world may have improved since last I checked, so please tell me if my experience is out of date. :)