haha updated to read "A setup script to get Ruby and Rails running on Ubuntu server in one line". The first draft of the script was one command originally.
This strikes me as no easier than rvm, but less clean (installations go to /usr/local, no easy way to switch between various ruby interpreters or gemsets, harder to uninstall, etc.).
Why not just do this?
1) Update whatever requirements you need via APT tool of choice.
2) Install rvm
3) Install ruby-1.9 using rvm
4) gem install rails
5) Write great rails app.
It's not too often that you'll have a server that runs two applications. Sure, if that were the case then you would be using RVM in which case I would recommend following the guide already linked.
But if you've got one application running one version of Ruby, then this is definitely a perfect way to go.
Is rvm commonly used for production or just development environments? I can see where having a script to get your production (or testing) environment up and running with minimal user work would be useful, but if this is meant for just development I agree with your point.
I use RVM for both development and production, and I've written scripts that use it to set up both my development and production machines. It's nice to be able to reformat my workstation (for new Ubuntu releases, or new hardware) and get back to business quickly. As far as production, I'm not really sure RVM is that much of a win, assuming you're compiling the latest Ruby anyway and have only one app on the server. I use it since I've yet to learn proper packaging and therefore the only (easy) way to uninstall a Ruby is via RVM (I know about checkinstall, but IME it's buggy as hell).
I totally agree that you should become fully comfortable with setting up a box manually. But when you perform the same setup over and over and have the process memorized as I do then writing a little shell script to get the job done never hurts.
And there's something in the inner-sysadmin in me that sees "curl http://example.com/foo.sh && ./foo.sh" and shudders. That sounds like a receipe for disaster.
That's what rvm is for. Leave the system Ruby alone and install your own, even multiple versions. I have ruby 1.8.7 with rails 2.3.5 and 1.9.2 with 3.0.3, easily switch between them for testing.
RVM is not beginner friendly because it has dependencies, it compiles stuff on your machine and there are dozens of problems waiting to happen because of that.
If wanting an easier way to install Rails for beginners makes me an idiot, then I'm proud of it ;)
I wouldn't say that rvm is not beginner friendly, but I grant that it has other requirements and compilation can break down due to specific library issues on different systems. To my mind, a better solution, however, would be a compromise: (1) write a script to automate the installation of all the prerequisites (packages and specific library versions) in one step using APT, but then (2) recommend using rvm after that.
Note that this solution also compiles stuff on your machine, and in this case it uses system-wide installation locations. One advantage of rvm is that everything is done as a regular user and sandboxed in $HOME/.rvm. Easy to find and remove, if anything goes wrong or you change your mind later.
Here is a script that I wrote and have been using, should work on most Linux's and OSX to bootstrap a Rails Development environment. Also ensures that git is installed. You can run it with one command (after reading it's contents of course) as follows:
-I've installed 1.8.7, 1.9.2 & 1.9.2-head via RVM without having libyaml-dev or libffi-dev installed (I see they're listed in `rvm notes`). Any idea what's up here?
Read the script, it's adjustable. Download, change your version and run. They are listed as they help 'cover all bases' as they are used by some gems that people might need.
If you are setting up enough VM's that you need this you should have something like puppet installed and don't need this. If you are setting up one machine then do it by hand. Know the tools you have installed and keep track of them it will make deployment easier.
This isn't meant for huge deployments or rollouts. I use it to setup testing servers that mimic production boxes. And yea it should ready "setup rails with one line"
Some comments & questions from someone who's worked on something similar:
-What's extglob used here for? I don't see any regexes.
-What are libffi-dev and libyaml-dev for? I assume some common gems depend on them. If so, which? (I'm just getting into Rails.)
-Git in the Maverick repos is old (1.7.1, which was released in April). Installing it from source is probably a better idea.
-You should probably use RVM to install Ruby, since its 1.9.2-head target won't require you to keep updating your script with 1.9.2's patchlevel.
-In my rails3.sh (which I should really publish), I didn't need to `gem install bundler` in order for `bundle install` to work. Probably because `rails` depends on `bundler`.
-That sudo check is neat, and I'd like to lift it; what's this script's license?
extglob is in there for future improvements. I plan to make it robust enough to accept parameters in the future.
When building Ruby the output complained about some missing deps. libffi-dev and libyaml-dev made Ruby stop complaining about them :)
Bundler is installed on the system because you don't have to install Rails on the system. You could simply put Ruby on there, install bundler then when you upload your app and run "bundle" it will pull down Rails and any gems your app depends on. Having Bundler available on the system is needed if you don't install the Rails gem system wide.
Use the script however you see fit and feel free to take from it what you like :)
Note to the wise: do not run this on a production machine unless you understand the full consequences of what the script is doing.
This is great for starting out a new machine and getting things setup, but running the update and upgrade commands without consideration of what's being updated could cause a lot of headaches if any existing sites running on the server have dependencies that are botched by the upgrade.
Just so you guys know this script has changed a lot since I opened it up. It now has way better output formatting, the option to install Ruby from source or RVM, better stdout and stderr redirection to the install.log and even captures signals for things like ctrl-c to kill the script nicely. Thanks for all the input and I hope it's found to be useful :)
Just a FYI I changed the script to install Ruby to /usr/local thanks to some input from a Github user. Also people are forking it and setting it up to install RVM so feel free to check those out as well!
I believe your earlier version already was installing to /usr/local. You've just made it explicit. Most configuration scripts accept a --prefix option, but default to /usr/local if you omit the option. I'm pretty sure that Ruby works that way, and it's exceedingly common. (Not that the explicitness isn't a good idea. You don't want to rely on a default without being sure.)
Follow-up: partial output of ./configure --help in a Ruby source directory:
> By default, `make install' will install all the files in `/usr/local/bin', `/usr/local/lib' etc. You can specify an installation prefix other than `/usr/local' using `--prefix', for instance `--prefix=$HOME'.
