Live data from Hacker News

Installing Rails on a Mac Shouldn't Be As Hard As It Is

cabforward.com

71–80 of 100 posts

Re: Installing Rails on a Mac Shouldn't Be As Hard As It Is

#71
post #28

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?

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.

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).

Re: Installing Rails on a Mac Shouldn't Be As Hard As It Is

#73

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…

> 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 ar…

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.

Re: Installing Rails on a Mac Shouldn't Be As Hard As It Is

#74

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/rail…

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

Re: Installing Rails on a Mac Shouldn't Be As Hard As It Is

#76
post #55

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…

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. N…

> 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.

Re: Installing Rails on a Mac Shouldn't Be As Hard As It Is

#77
post #42

Earlier quoted context omitted.

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

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.)

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

Re: Installing Rails on a Mac Shouldn't Be As Hard As It Is

#78
post #55

Earlier quoted context omitted.

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. N…

> 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 p…

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.

Re: Installing Rails on a Mac Shouldn't Be As Hard As It Is

#79
My tutorial (http://www.moncefbelyamani.com/how-to-install-xcode-homebrew...) 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.

Re: Installing Rails on a Mac Shouldn't Be As Hard As It Is

#80

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…

You forget what it is like to be a beginner.

It's not programmers new to Ruby that you need to worry about. It's people new to programming. Understanding dot files, ruby managers (RVM or rbenv, which do I use??), Ruby (do I want 3.9.1 or 3.9.1 p58, what the hell is a patch file?), random Bash errors, etc.

Having learned Ruby a few months ago, it was honestly pretty daunting. Now, I also think it's pretty simple. And if I tried to learn a new language with a similar mess of issues, I would probably think it's "easy enough". But this is not how the default should be, and this is not how new people should have to learn.

There are easier ways.

Post reply on HN