A Ruby Appliance
Tuesday, December 29th, 2009What is an “Appliance”?
In this context, an appliance is a ready-to-run virtual machine. No set up to speak of required.
But why? Isn’t it easy to install Ruby wherever you like?
That is very true.
However, the Ruby ecosystem is very *NIX centric. Not everyone has the luxury, or time or ability, to setup and maintain a UNIX-like operating system.
Virtualization and thus appliances turn operating systems into just another kind of program. They reduce the risk of using a different operating system. Further, not everyone using Ruby wants to, or can, dig through C extensions to make them work on their operating system of choice. The hurdles as a Windows user are too high in most cases.
An appliance makes it easier to setup test environments, so they are great for seasoned developers, as well!
You can start with a clean slate, only Ruby, RubyGems, and a compiler tool chain are installed, and you can easily revert to this blank slate at the push of a button. With the different networking tools in today’s VM tools, you can even test network deployment of Rails applications.
So here is my proposal:
To create the best possible Ruby appliance and experience, I want to know which Gems and tools the Ruby community sees as essential to make life as a Rubyist easier.
Submit your ideas, and the Ruby Appliance will benefit and with that, all of the Ruby community.
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=2f52bc3c-e4f2-408a-b8fe-cde0df8e11b3)
Biggest thing I’d suggest is multiple VMs.
I’m actually not sure of the best way to do this — the way I do it currently results in a ton of duplication with the gems, at least. But I currently have Ruby 1.8, Ruby 1.9, and JRuby installed.
Yeah, I plan to do two VMs at least:
One for developers (plain Ruby + RubyGems + compiler tools), and one for Ruby newbies, who want to explore the language (built on top of the developer version, but interesting gems being included out-of-the-box).
While I generally think it is a great idea I believe you won’t get any consensus on what to include (just think about the choice of text editor). Including all of them is probably also not a good idea – at least for the “starters edition”. Too many choices make things more difficult when you try to start.
Having said that the best approach is probably to just do it and then listen on the user feedback. My 0.02EUR…
Of course choices will have to be made as to what to include.
But before this choice can be made, a survey is necessary to see what’s in wide-enough use to make it worth while to include (i.e. in that there is enough support for it available).
I absolutely expect that there’ll be vim vs EMACS lobbying and similar.. religious issues.
The decision what to include has to be postponed for a while, at least until I can build a solid experience for newbies out-of-the box, and distribution issues need to be handled, as well (if the image were to include NetBeans, how are Java and NB distributed / redistributable, for example).
Git is the first thing that springs to mind – it would feel weird working on a system without it. Beyond that, the MySQL client bits would probably be very useful, even though SQLite is better for initial development.
I know that I’m developing Hackety Hack in an Ubuntu VM under VirtualBox right now, so I can see a use for this.
I’d say pay attention to how similar projects have worked in the past. For instance, I see similarities to the Haskell Platform and Instant Rails.
Also, it’d be nice if there were a good way to cross-compile apps. I’m not sure what tools this would take, because I have no real experience with it yet, but being able to still make Windows or OSX apps inside of the Appliance would be nice, otherwise, its utility is limited.
The idea is, eventually, to have an evolution of InstantRails and the RubyOneClick Installer at hand: Launch the VM, and get going, with all the tools you need.
For beginners, there have to be easy, accessible tutorials manuals, and references at hand, which’ll probably require modification to RDoc output (the default is fine and servicable, but not quite as useful as it could be for utter beginners).
Also, having cross-compile capabilities is certainly a nice feature for a “Developer VM”. I know that there are MinGW and MSYS packages available for Linux, so it’d be more an issue of creating sensible defaults where the builds ends up to make packaging a breeze (ideally: “rake gem:build:all:publish”, basically).
Regarding Mac OS X: No clue if that works (it should, knowing how OSS works), or how (which should be possible to be researched).
WRT cross-compilation, I know that several Ruby projects use rake-compiler for handling native extensions: http://github.com/luislavena/rake-compiler/
Skimming the README, it seems to sit on top of GCC and MinGW.
I know, I helped test it, back in the day when it was a bootstrapper to get Ruby compiled in MinGW.
If rake-compiler has a GCC 4 option, that’s from me. If not, I’ll have to whine about it on my blog. Oh, wait…
[...] yeah, the Ruby Appliance isn’t forgotten. Considering that this was between the years we did get quite a bit done yet. [...]