
Installing Rails on a Mac Shouldn't Be As Hard As It Is - bluedevil2k
http://cabforward.com/blog/install-ruby-on-rails-on-mac
======
nicholassmith
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.

~~~
crazygringo
> _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!

~~~
eipipuz
I agree that there must be a better way, but I need to point it out.

Ruby does come with Mac. Ruby is not Rails. The default installation allows
anyone to try Ruby.

------
martingordon
Yehuda Katz is working on a Mac app that sets Rails up on a Mac:
<http://www.kickstarter.com/projects/1397300529/railsapp>

Also see this relevant (and relatively recent) update on the project:
[http://yehudakatz.com/2012/06/05/tokaido-status-update-
imple...](http://yehudakatz.com/2012/06/05/tokaido-status-update-
implementation-details/)

------
JonnieCache
Far too high a proportion of the questions in #ruby are about installation.

Often people come in having (naturally) tried to install it from their
distro's package manager. First we have to explain to them why this is a bad
idea and persuade them to remove it. Then, often they have tried to install it
from source, passing some fucked up value to --prefix, and they have to be
helped to clean that mess up.

Then we tell them to use rvm, but someone pipes up about rbenv and friends and
we have to explain the differences. Then it turns out that they didn't have
openssl-dev or something installed so they have to recompile ruby _again_ , or
someone has to try and remember the magic spell to compile the openssl bit of
ruby separately, which nobody ever can.

 _THEN_ it turns out that all they want to do with ruby is run redmine, which
has some other specific requirements that nobody in the channel knows or cares
about.

Basically, when yehuda katz finishes that project of his, freenode will be
measurably happier, although the problems with OS packages will remain, I
imagine forever.

The real root of the problem is that a lot of the things which make the ruby
ecosystem highly dysfunctional are the same things that make it so great.
Primarily the fast pace.

~~~
davidw
I use and love Ruby every day, but this package management business is ...
irksome. First the Ruby guys crapped all over package management from Debian,
who, despite their shortcomings, _have_ been doing it a while and know a thing
or two about it. That wasn't entirely unfounded, because there were some messy
things there, and the intersection of two different package management systems
is bound to be a bit confused.

Now we have rvm's and gemsets and bundles and additionally people trying to
foist off alternatives to some of these, and the whole thing is beginning to
look like an unholy mess.

Meanwhile, Debian/Ubuntu's package management continues to work pretty well at
what it does.

~~~
dasil003
> _Meanwhile, Debian/Ubuntu's package management continues to work pretty well
> at what it does._

But what it does moves at about 10% of the speed of the ruby community (at
least post-Rails). I'm not saying that the ruby culture is better—it obviously
has serious consequences for stability and leads to all manner of headaches.
However it does mean that if a new and better idea of how to do something
comes out, Ruby is probably one of the first places you can use it in
production.

My feeling is that the benefits outweigh the costs if and only if you are a
full-time developer in a paradigm that Ruby is good for (eg. traditional web
development). If you are just dabbling in the language then Ruby will
continuously pull the rug out from under you. And if you are just trying to
install some software as an end-user, then Ruby is probably one of the worst
possible platforms.

~~~
davidw
I didn't meant to say that Ruby should use Debian package management or
anything like that: it needs its own stuff at its own speed. More that they
should be a bit slower on the draw when it comes to pissing on other people's
work.

~~~
dasil003
Agreed that the subset of the community with no respect for the Debian process
showed the worst sort of young hipster developer arrogance.

------
pavel_lishin

        $ /usr/bin/ruby -e "$(/usr/bin/curl -fksSL http://bit.ly/HyK0NG)
    

That looks terrifying.

~~~
rmc
Too often you see advice like that. And this is supposed to be from technical
users who know about security. And we wonder why mundanes click on spyware
scams…

~~~
JonnieCache
How is it any different from downloading any other code and running it?

Are you saying you audit every piece of unsigned code you run?

I admit that putting bit.ly into the chain of trust is quite a bold step, but
is it really _that_ different to, say, the rubygems server? Or your wireless
router?

EDIT: also, LOL at "mundanes."

~~~
TylerE
Imagine Bit.ly gets backdoored, and that shortlink is repointed at a script
that just contains rm -rf /

~~~
JonnieCache
Imagine your wifi box gets backdoored.

Imagine your ISP's router gets backdoored.

Imagine if the server you got your bash from gets backdoored.

Imagine if the rails repo gets backdoored.

Imagine if the plant where apple images the macbook HDDs gets backdoored.

Imagine all the people, living for today...

(But yeah, personally, I'd forgo the bit.ly part as its unnecessary.)

~~~
pavel_lishin
I could also imagine that someone wired up my car to explode, but there's a
reasonable level of paranoia. Link shorteners are fairly frequently used to
hide the true destination of a link.

Although, I wonder how hard it would be to set up some text with CSS that
looks like one string, but is actually another. e.g. the user would see

    
    
        https://raw.github.com/mxcl/homebrew/master/Library/Contributions/install_homebrew.rb
    

but when copied-and-pasted is revealed to actually be something like

    
    
        https://raw.github.com/mxel/homebrew/master/Library/Contributions/install_homebrew.rb

------
dansingerman
I am not sure installing a full stack web framework, a version control system,
and automated deployment to public hosting should be _that_ easy. Learning how
to install it all is very informative as to what is going on.

e.g. Deploying to Heroku is in fact very easy. Ok you have to mess around with
ssh keys, but you don't want that to be automagic - you want to have some
understanding of why what you are doing is secure, and why anyone else can't
access your code.

~~~
j45
If you want it to replace php (or anything), it has to be as accessible as php
for the same developer.

Until then, all the conversation about standards, best practices, and
tutorials are far less accessible.

~~~
philwelch
The purpose of Rails isn't to replace PHP.

~~~
j45
It might not be, but our Rails heads sure do like talking about PHP a lot.

If a technology is truly supposed to be accessible it needs to actually, be
accessible instead of carrying an air of superiority, otherwise software
continues to suffer.

~~~
philwelch
Rails isn't supposed to be accessible the way PHP is, i.e. built into every
shared hosting account with unlimited flexibility as to what you can do with
it. If that was the right way to go for web applications, there would have
been no need for Rails in the first place, since PHP would have been
sufficient.

~~~
j45
I'm not sure where it was said PHP is only shared hosting. Besides, many
places start on shared hosting, kind of like Heroku for rails code, no?

I'm also not sure where the idea is coming from that Rails shouldn't be
accessible to developers. If you have some wider posts or links I'd love to
read some more.

~~~
philwelch
Rails is accessible to developers who have a baseline of competence. PHP is
accessible to complete beginners.

~~~
j45
Again, is that your opinion / preference, or can you share a source? Most
interested to see where this is coming from beyond things I could google
myself.

------
monfresh
My tutorial ([http://www.moncefbelyamani.com/how-to-install-xcode-
homebrew...](http://www.moncefbelyamani.com/how-to-install-xcode-homebrew-git-
rvm-ruby-on-mac/)) is mentioned in the article, and at the time I wrote it
(back in March), those were the steps necessary to install all of those tools.

I published it to help others avoid the pain I went through, and to share what
I've learned so far. Given that it has had over 15,000 views so far (mostly
search traffic), I'd say it's doing its job.

A few weeks ago, I used my own tutorial to set up a new MacBook Pro, and
noticed that the latest version of the Xcode Command Line Tools and Homebrew
seem to play well now. Originally, the separate CLT download from Apple and
Kenneth Reitz's osx-gcc-installer resulted in errors when installing Homebrew,
but I'm planning on trying them again soon and updating my tutorial with my
findings.

I'm also planning on evaluating the new RailsInstaller for Mac, but when
starting out, I recommend learning the hard way to understand what each tool
does and to pick up some basic command line skills.

------
JohnBooty
I'm coming from a Windows world, where installing Rails and all the tools is
as easy as hitting up RailsInstaller.org, downloading an .exe file, and having
my environment set up in a few minutes.

Uh, what? <http://railsinstaller.org/> has a Mac version too!

It's right on their home page (if you're browsing from a Mac; it shows you the
Windows version if you're browsing from Windows...)

[https://github.com/downloads/railsinstaller/railsinstaller-n...](https://github.com/downloads/railsinstaller/railsinstaller-
nix/RailsInstaller-1.0.1-osx-10.7.app.tgz)

~~~
stephenhuey
That's new. They just announced the Mac OS X version on June 1st:
<http://www.engineyard.com/blog/2012/railsinstaller-for-os-x/>

------
programminggeek
Doing ruby dev in a VM is pretty nice for some things, and terrible for
others. In general, I think VM's are great if you have a team and need to get
environments setup that work on any machine (windows/mac/linux). Where it
falls flat is in some weird places like if you want to use Guard for automatic
file change actions. Otherwise, it's pretty awesome.

If I'm working on my own projects tho, running ruby local on OS X is the way
to go. Much less overhead.

------
jff
I think this is partly why so many of my Mac-using colleagues have a Linux VM
for doing development; every programming-type task I tried to do on my Mac was
an exercise in frustration. At least there's finally a set of command-line
compilers you can get without having to download XCode (it's free, once you
pay $99 to become a developer! I thought I already was a developer, which is
why I want compilers...)

Personally, I just installed Arch Linux on my Air. With the SSD, it boots in
seconds, even on an encrypted root. I can use whatever window manager I want,
and all the tools _I_ need for work are there or easily accessible. No hoops,
no tricks, no outsmarting the operating system.

~~~
veyron
There's a free 200MB download of the command line build utilities. Xcode
proper (4+ GB) is also free ...

~~~
jff
I was unable to find free versions of either of these, for Snow Leopard, when
I looked a year ago. At that time, Lion was utterly unusable (not sure if it's
any better), so I just gave up and got a Linux VM for that laptop.

------
molecule
> Installing Rails on a Mac Shouldn't Be As Hard As It Is (cabforward.com)

1\. Editorialized headline

2\. It's easier than this article-- you don't have to install XCode:
<https://github.com/kennethreitz/osx-gcc-installer/>

3\. There are some smart folks working hard to make it easier:
<http://www.kickstarter.com/projects/1397300529/railsapp>

~~~
brudgers
I believe the author's headline is justified within the article:

 _"I'm coming from a Windows world, where installing Rails and all the tools
is as easy as hitting up RailsInstaller.org, downloading an .exe file, and
having my environment set up in a few minutes."_

------
DanielKehoe
The author points to my article: <http://railsapps.github.com/installing-
rails.html>

I titled my article "Read This Before Installing Rails" because Rails is not
just a Ruby gem, it is a complex and rapidly evolving ecosystem. Sure, if you
want to see Rails running on your Mac you can use the installed system Ruby
1.8.7 and "gem install rails". But if you want to do development, you'll need
to update (and keep updated) all the related gems and packages that are an
essential part of the Rails habitat. Judging from the comments and help
requests I see, that's not easy.

Packages such as RailsInstaller, Cinderella or the BitNami RubyStack are great
but they inevitably slip further and further behind the evolving state of the
Rails ecosystem. I'm hoping the design of Yehuda Katz's Tokaido will avoid
this issue. In the meantime, yes, it's difficult to install (and keep current)
a useful and fully functioning Rails development environment on a Mac (or any
other machine!). I say that from the experience of attempting to keep my
"Installing Rails" article current.

For example, would you like to develop using Ruby 1.9.3 (the current
recommended version) and deploy to Heroku (which now supports Ruby 1.9.3)?
You'll need to update to the unreleased 1.2.0.pre.1 bundler (which requires a
"gem uninstall" not a "gem update"). That's true today. Maybe it'll change
tomorrow.

A rapidly evolving ecosystem is not a bad thing. Rails is a powerful, widely
used, and well-supported development platform. The constant changes bring
increased utility. If you can keep up and find the right advice. The author's
article is sound and offers some of that good advice.

------
getsat

      user@brand-new-mac $ which rails
      /usr/bin/rails
    

What? OSX has shipped with (some version of) Rails since Leopard. You don't
need to install a compiler or compile anything to use Rails on a Mac. It comes
with sqlite3, too.

~~~
lloeki

        $ /usr/bin/rails
        Rails is not currently installed on this system. To get the latest version, simply type:
        
            $ sudo gem install rails
        
        You can then rerun your "rails" command.
    

> The basic database program that Rails uses is SQLLite3, and you will need to
> install this to work with it.

yet Tiger had sqlite3 already.

What's more, Ruby is installed already. One can 'gem install rails' and have
the latest version landing in /Library/Ruby/Gems

~~~
calinet6
While this is _technically_ true, it's important to note that it's not usually
desired.

You should be running a fairly recent version to keep up with patches or match
your server, you should be running RVM so you can keep a gemset and use
bundler, and you should use homebrew to make installing other packages easier.

Not that any of that is difficult, and you're right to a degree: you can get
started learning using one command and go from there.

It's really not that complicated.

------
eli
Unless you're planning to deploy to a production server running OS X, I don't
see why you'd care about Rails running natively on your Mac.

Why not develop against a VM running the same OS as your server?

~~~
crazygringo
Why on earth should you have to run a VM in order to run a programming
language?

This hasn't solved the problem of Ruby being difficult to install, it's just
added ANOTHER problem of having to learn to install a VM manager and a whole
new OS, plus using up far more system resources. Seems to me like that's just
making things worse.

~~~
eli
Why on earth should you have to recreate your _sever_ stack on a _desktop_ OS?
Seems like you're just begging to be bitten by some OS-specific bug or quirk.

It solves the problem of Rails being hard to install on OS X... because it
obviates the need to install Rails on OS X. And there's no new OS to learn --
the VM runs the same thing as your server. If you don't know how to use the OS
that's running on your production server, that's a bigger problem.

I've been developing this way for years. Additional benefits include: you can
easily have multiple VMs with different configurations, you can
snapshot/backup/restore a VM very easily, crashing a VM doesn't crash your
computer, and it's relatively easy to share a fully configured VM with another
developer (even if their primary OS is something totally different).

~~~
dasil003
I see it as being a bit like moving to a service-oriented architecture. When
you're just getting started it adds overhead, but by the time you get to your
5th developer or platform-dependent bug (hello HFS case-insensitivity bugs!),
maintaining a VM image starts to make a ton of sense.

Similarly, when you start a new web app, of course a monolithic framework like
Rails is great and is flexible enough to roll in all your business logic.
Somewhere around 50k lines though, you start getting that ball of mud feeling
and managing changes across the entire code base starts to become onerous. At
that point you realize the sysadmin overhead, and cost of defining and
maintaining slow-moving services interfaces allows you to turn your ten-person
team into ten ten-person teams and get a reasonable productivity multiple out
of the deal.

------
vbl
As a non-developer who has tried several times to learn, I can say with 100%
confidence that setting up a dev environment and workflow is fucking
maddening.

It's a major barrier to learning and I hate that it's as complex as it is.
Should be turn-key.

~~~
kaonashi
The thing is though, you need to be familiar the tools involved with
installing the system in order to use the system. It might present a bit of a
learning curve up front, but I think you'll be better off.

Now try installing rails on a windows machine; that's the real pain in the
ass.

------
ridruejo
Have you tried RubyStack (<http://bitnami.org/stack/rubystack>) In addition to
Ruby runtime + Rails we include many of those components mentioined above such
as SQLite, RVM, MySQL. Free and self-contained (so if you don't like it you
can simply remove the installation directory) It works the same across
Windows, Linux, OS X

------
jenius
I got frustrated with this as well and decided to make it easier. Here is my
solution:

<http://up.jenius.me>

------
koryteg
i found this article very encouraging. first i started developing on a windows
7 machine, before "railsinstaller.exe" was around. It was a pain to setup.
soon after i was able to get my hands on a mac. still being pretty new to
rails it was a whole new world of learning; git, ssh, .bash_profile, unix
commands, figuring out gemsets on rvm, why one rails app would install
rmagick, but another would error out, what the hell is GCC?

working through these things was a huge help and eye opening experience for
me. being new to OOP and web app development it seems like there is a never
ending list of things to learn, and everyone out there with their computer
science degree has the knowledge already that i am missing. so i guess it is
encouraging to see a list of things that this "engineyard training provider"
is struggling with, and i worked through it all and have a pretty good grasp
on now.

------
neilkelty
Try this - <https://github.com/kelsmj/macsetup>

------
mirceagoia
It shouldn't be, but try on Linux...it's even worst than on Mac. That's why I
made this 35 page tutorial: [http://www.mirceagoia.com/2011/11/ruby-on-rails-
installation...](http://www.mirceagoia.com/2011/11/ruby-on-rails-installation-
ubuntu-linux-mint/)

------
lexy0202
Wow, this is somewhat ridiculous. I just clean installed Lion on my MBP.
Installed Xcode form MAS, installed the Xcode command line tools (in the
prefs), and ran curl -L <https://get.rvm.io> | bash -s stable --rails. Done.

------
saltcod
Installing Rails and most everything else was simple for me. Getting mysql
hooked up proved to be much more troublesome. Especially with MAMP installed
already. I wish it would install in a contained package and not mess with
anything else.

------
paulmwatson1
Is nobody worried that this developer wonders out loud why he can't re-use his
GitHub key with Heroku? Basic knowledge seems missing.

------
jroes
How about <https://github.com/thoughtbot/laptop>

------
andrewvc
I'm pretty happy with vagrant images.

Ultimately, putting your dev environment on a server image makes way more
sense.

------
johnkpush
I thought the Rails install process couldn't be easier, and I don't even like
Rails... _ducks_

------
tortilla
I love cinderella:

<http://www.atmos.org/cinderella/>

------
adriand
For Postgres, I really recommend postgresapp.com.

~~~
masklinn
Only works if you downgrade from SL to Lion though.

~~~
telemachos
I've used Postgres.app recently on Lion. What problem did you have?

~~~
masklinn
Lion is the problem I have.

------
pjchristie
This is very helpful

------
z_
Your first mistake is installing Rails. You're second mistake is attempting to
do so on your development machine and not in a jail or vm.

~~~
shane_mcd
Not sure why you'd recommend installing Rails in a VM? It's a framework, not
an environment.

~~~
technomancy
You want development to match production as closely as possible, otherwise
you're setting yourself up for nasty surprises down the line.

~~~
crazygringo
No, you want _testing_ to match production as closely as possible.

Much of the time, development can be done in all sorts of ways that needs
little connection to the final production environment.

