Your list is far from canonical even at this very moment and hasn't even been common for very long. To figure out your list, I have to:

1) know that homebrew is the "right" way to install software that rails depends on, rather than MacPorts or Fink, or the Mac app store, or download.com, and oh yeah, there is this thing called sudo, and I should install homebrew recipes using it, or should I??,

2) know that rbenv and ruby-build are things that exist and that they are competitors to RVM but are either more or less in vogue depending on who I talk to,

3) understand that rbenv doesn't just work in the current shell without closing and re-opening it,

4) know that the "right" version of ruby to use is 1.9.2-p290 (I have to know the patch-number?!) and that I need to install it and set it as my local version (wait, what does that mean, why do I need a local version?),

before I can get around to actually installing rails and using it.

Now, I could just blindly follow someone's list from a blog post (randomly chosen presumably, because the theory here is that I don't know enough about these things to make an informed decision). Maybe I would even get lucky and find a list that works properly with the version of rails that the official documentation is talking about, but it would still be a much better experience by far to go to the official rails site and be told: "hey, download this all-inclusive, up-to-date, guaranteed to work disk image straight from us!".

No. You have to know none of that. You just have to copy/paste the steps from the rails-homepage (where they should be prominently listed, the lack thereof is the real bug).

"hey, download this all-inclusive, up-to-date, guaranteed to work disk image straight from us!"

Wait, how is that different from above?

Yes, you may be done 2 minutes faster. But you just deprived yourself of at least getting a glimpse on which parts are involved, even if you don't understand them yet. That means you're now even more hopeless when stuff breaks later (and stuff always breaks later).

And as a fun fact: Any sane bootstrapper would use the exact same script behind the scenes anyway. There simply is no other way unless you plan to re-invent homebrew and rbenv along the way.

I'm really troubled to understand who we're trying to care for here. It sounds like you want to make this Really Easy for absolute beginners who can barely setup a printer.

That is a noble goal (for a printer driver), but if you want to teach someone programming then there's a point where you have to stop dumbing it down artificially. And that point is as early as possible.

The worst you can do to a newbie is to put him into an opaque sandbox with different behaviors and errors from what the "big guys" are using.

2. sudo brew install {postgresql,rbenv,ruby-build}

3. Close terminal. Open terminal.

4. mkdir proj && cd proj && rbenv install 1.9.2-p290 && rbenv local 1.9.2-p290

5. gem install rails && rbenv rehash

6. rails new foo

-------------------

"hey, download this all-inclusive, up-to-date, guaranteed to work disk image straight from us!"

Wait, how is that different from above?

-------------------

Really? You really have to ask how those two processes are different?

"stop dumbing it down artificially"

If (sometimes competing) complexities weren't continually added, there wouldn't be a need to 'dumb it down'.

"(and stuff always breaks later)"

Wow. Most other web framework communities don't have that much problems with 'stuff always breaking later'. Maybe Rails has reached a tipping point?

"There simply is no other way unless you plan to re-invent homebrew and rbenv along the way."

Or until someone else does 'reinvent' one of those, and all the cool kids start using it, leaving everyone who learned the 'legacy' way out in the cold without an upgrade path beyond "start over".

with different behaviors and errors from what the "big guys" are using

I think part of the purpose of the kickstarter project is having one of the 'big guys' behind it. Supposedly that would mean at least one (or more) of the 'big guys' would indeed be using the same process as the 'newbs', reducing this chasm.

Sounds like you're threatened some by this - it was hard for you, therefore it should always be hard for everyone for now and forever.

Yes, I'm threatened by this. But not in the way you think, because as shown above, it's not really hard. It's 5 lines. What's wrong with kids these days?

I'm threatened because I'm the guy who comes in to clean up after "junior programmers" who couldn't even be bothered to learn 5 lines to install their dev-environment and who consequently also don't have the slightest clue about basic realities such as "diskspace is finite" or "No, /Users/Bob/rails/tmp is not a valid path in production".

At least give the kids a chance to learn. Don't lure them with shortcuts that result in unsustainable habits that cause great frustration in the long run. Unlearning is harder than learning.

Rails with its false sense of simplicity is breeding plenty diletantes already as it is. We need less of that, not more.

Would you mind scrolling up to my original comment where I posted the exact 5 lines?

My designers need to work with my Rails apps

Then you should have noticed that installing rails is the least of your worries. Database seeds, missing dependencies, test-users, broken fixtures, broken mocks, missing external APIs, version control conflicts, gem screw-ups, failing migrations, rails upgrades, differences to the production setup. Those are the daily timesinks over here in the real world.

The initial rails installation doesn't even register in the grand scheme of things.

1) The rails.app project wants to solve a problem that doesn't exist. There are a lot of comments here from other people who think getting started with rails is confusing, and who point out that your much-touted five steps are not complete, canonical, or easy, so I won't further beat that dead horse.

2) There are many harder problems you'll come across when doing rails professionally. This is incredibly true, nobody disagrees, but it's irrelevant to the rails.app project.

If you are someone who doesn't know what it means you should learn. Isn't that what a programmer needs to do?

Reading your short list triggered a flashback. I struggled with everything you listed, probably more.

When I made a run at getting an existing RoR project running on my Mac (~1 year ago), there was no shortage of howtos and advice. The problem was resolving all the contradictory information.

As moe points out, the project home page should have the single source of validated truth on how to get RoR running on a Mac. Minimally.

That such a source of truth didn't exist led me to conclude that Rails was run by amateurs and to not be taken seriously.

But, they break.

Would you like to start a pool on how long it will be until this recipe breaks, or becomes hopelessly obsolete because some portion of it is now out of date?

Hint one: To get an idea, one could try the problem in reverse: How far back in time can you go before you reach a time when this script would not have worked yet? (Hint one, sub-hint A: The first commit to Homebrew's Git repo was in May of 2009.)

Hint two: Homebrew formulae aren't guaranteed to build at all times. They sometimes have bugs, especially when any of their dependencies (including the version of OS X itself) has recently changed. Those bugs tend to manifest as scary messages from (e.g.) the linker.

Hint three: Better get that version number out of the recipe before placing the bet. 1.9.2-p290 could become hopelessly obsolete at literally any minute; we're always just one zero-day away. It would be more reliable to pull that number from some canonical source like… um, any ideas? What is the answer to the question "how can I reliably determine, at any time over the next five years, the latest, least-buggy version of Ruby that is compatible with the version of Rails that I've got installed on my machine?" I don't know what your answer might be, but mine would be "pay someone like Yehuda Katz or the Rails core team to continuously recompute the answer, and to maintain the website that hosts the answer".

But, they break.

The rails-answer would be "so is life". My answer is: Then fix it, damnit. Not you personally, but the maintainers. We must stop accepting constant wreckage as an inherent property of the rails-ecosystem. It is not inherent. Other systems such as debian APT work pretty flawlessly under significantly more complex conditions (thousands of packages on multiple architectures, for starters).

Isn't rails the one with the 17 different testing frameworks and TDD kool-aid? How about adding structured tests for the installation procedure, too?

Keeping a ruby/rails installation procedure functional is not rocket science. And in defense of the actors: I do consider the current state-of-the-art (rbenv, bundler) to be fairly close to something that one could call reasonable.

Hint one, two, three

The exact same applies to any installer that you may come up with. It either has to perform the famous 5-steps behind the scenes, or it has to re-invent all the tooling that is only now barely stabilizing (square 1 again, really?).

answer to the question "how can I reliably determine, at any time over the next five years, the latest, least-buggy version of Ruby that is compatible with the version of Rails that I've got installed on my machine?"

That is the wrong question. The correct question is "how do I install a self-contained rails runtime environment on my current machine" (which includes ruby and all core-dependencies).

The current answer is the above script. If the preferred tools change for a platform then update the procedure accordingly. Keep the current procedure in plain view in the documentation (Section 1: Installation).

It's not as hard as you make it out to be, really.

Install Xcode; 1) Install in App Store 2) Still not actually installed, start it, that finished the installation 3) You still don't have what you need, find where they've moved "install command line tools" to and install that 4)The compiler you have isn't the right one as Lion no longer has GCC as its default compiler and you want to use RVM 5) ......

Once you've done it a few times it's not that hard and you get used to knowing where to look for problems but the first few times it can easily be half a day lost just trying to get the environment working.

The above steps are reasonably robust and implicitly teach you things about your programming environment that you must learn (or at least have seen) as early as possible.

We should decidedly not dumb that down. There must be one canonical installation procedure for everyone and it must be as easy as above. There must not be "an easy way" and "a hard way". The above is as easy as you can make it without hiding crucial information from the user.

Rails has plenty of harmful padding already, we need less of that, not more.

The complexities of setting up a system so you can develop rails on it exist to solve problems that experts have discovered through years of working with the system, but which people coming to it fresh don't, and shouldn't need to, know that they have yet.