Maybe I'm coming at this from a different perspective as I've spent a number of years doing that whole "NINJAS BUILD FROM SRC.TAR" thing, but installing Rails under Mac has always been pretty straight forward. Get RVM > Get Ruby Version X > RubyGems > Rails > then fork off for databases if I want something fancy.
You are installing something that by it's nature requires a bit more understanding that just clicking on a .exe. Do you want to replace the default Ruby setup, which could potentially be used by something? Do you want to install new database servers? Do you want to modify Apache? Do you want to fiddle with SSH key gens? Do you want to have to delve in and change items of your .bash_profile? Do you trust an automated installer to be able to do it reliably on every single machine?
I'm not sure I'd have the confidence in something not going wrong and then sitting there with a half broken machine wondering what. At least this way at every step you can do the install > check & verify > confirm steps and make sure it's all business as normal.
> You are installing something that by it's nature requires a bit more understanding that just clicking on a .exe.
Well the default installation shouldn't. The default installation should be for someone who just wants to try Ruby out, that will just set things up to work, and won't interfere with anything else on the system (except for integrating with the webserver you're using). Like PHP does. Then they can mess around with Ruby, and as they learn about it, go back and change the installation or re-install as necessary.
> Do you trust an automated installer to be able to do it reliably on every single machine?
Well, yeah. Isn't that what installers are for? They're written by the team that developed the software. I assume they have a much better idea of how to properly install it than I do!
Sure, and if it's nicely sandboxed away and running in a bubble then it's perfect, if however it requires hooks into the system, which is the current paradigm, then they can't cover all cases. What if you have a custom bash profile and it kills it? Or some mix of packages throws a curve ball? At the end of the day you should know your system and requirements more than a faraway team, which reduces the risk.
But is RVM really that hard? If you are on a major distribution of Linux or OSX, all you have to do is install the dependencies and then copy and paste the bash command that setups up RVM.
The hangup is usually installing the dependencies. I remember on Ubuntu this involved hunting down one library that wasn't listed on the RVM wiki. Maybe that needs to be fixed with either more documentation on the RVM wiki or a Ubuntu RVM package (that package probably already exists).
On OS X it requires getting GCC to work, again maybe that needs to be clearer on the RVM wiki.
On windows - well on windows I just install a Ubuntu VM and go back to that installation.
But fixing those simple things (documentation, possibly RVM package) is far easier than creating a whole new installation process.
As someone who has just begun to learn to program (I finished JS lessons on Codecademy two weeks ago), I could attest that the Rails installation was quite daunting. Had I read about the "straight-forward" path you mentioned back then, I'd have just seen "Get acronym > which version of Ruby > What is a gem > Rails > what the hell is fork ".The last thing I want when trying out a new language is to be presented a smorgasbord of options that showcases language's capabilities, but all of which I have little understanding of.
I see this process somewhat analogous to learning a new musical instrument, like a violin. A professional violinist may care to customize many aspects of the instrument to meet his or her needs, including the turning of the instrument (perhaps he cares to set A to 416 to emulate Baroque turning). A beginner, by contrast, would just like to be handed a well tuned instrument ready to learn and experiment. Now, would it kill that beginner to set and tune his own set of strings, or maybe given the options to set his violin to Baroque turning as well? Certainly not - though the necessity and benefits of such an exercise would surely be lost on many beginners.
There's many different ways to install Rails and those will always be available whether someone creates an installer or not as long as source code is available. However, there is a combination of Ruby, Rails, and the database choices that serve as its backend which are common for the "Make a new Rails app and ship to Heroku" workflow that should be easier for being so popular.
I'm really surprised Rails isn't just another component in the Heroku toolbelt. The default Ruby version in OS X is always outdated, the database preferred by Heroku (postgres) is also outdated in OS X, and getting the latest XCode or re-installing it to install brew to install postgres and changing the order of execution in the PATH to make sure it picks up the right version is a prescription for despair and angst. RVM only solves the Ruby and gem versioning problem.
>You are installing something that by it's nature requires a bit more understanding that just clicking on a .exe.
I don't think it inherently require anything like that for _installing_.
There is essential complexity (e.g the complexity of developing a RoR app), and accidental, inessential, complexity.
Installation not being a one click / command process is inessential complexity. It's just that the people involved (and the people NOT involved) have failed to make it any better.
For example, one can install Apache/PHP/MySQL on a Mac in a single package in 1 minute (via MAMP).
The php interpreter isn't used by system processes. I'm not sure how essential the stock Ruby interpreter, but I know that on Linux the system Perl & Python interpreters are used by system processes and upgrading them could potentially break things.
Sure, but when that complexity is so utterly minuscule, what's the point in shielding users from it? Especially when you could argue that it benefits the user who will, at the very least, roughly know what's powering his application?
You are installing something that by it's nature requires a bit more understanding that just clicking on a .exe. Do you want to replace the default Ruby setup, which could potentially be used by something? Do you want to install new database servers? Do you want to modify Apache? Do you want to fiddle with SSH key gens? Do you want to have to delve in and change items of your .bash_profile? Do you trust an automated installer to be able to do it reliably on every single machine?
I'm not sure I'd have the confidence in something not going wrong and then sitting there with a half broken machine wondering what. At least this way at every step you can do the install > check & verify > confirm steps and make sure it's all business as normal.