Live data from Hacker News

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

cabforward.com

61–70 of 100 posts

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

#61
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…

Until you have more than one app running on the same machine with different dependencies... like say on a development machine. This is the point when bundling shines, because it elevates you off of the os-level dependencies.

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

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

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

#65

Earlier quoted context omitted.

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

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

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.

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

#66

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

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

#68
post #61
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…

Until you have more than one app running on the same machine with different dependencies... like say on a development machine. This is the point when bundling shines, because it elevates you off of the os-level dependencies.

A properly done OS can handle more than one version of a library at the same time.

Also, it's a good idea to use a development environment that's not too far from what you're running in production.

Post reply on HN