Live data from Hacker News

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

cabforward.com

91–100 of 100 posts

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

#91

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…

[deleted]

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

#92
post #59

Earlier quoted context omitted.

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.

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.

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

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

#93

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…

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.

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

#94
post #33
post #14

Earlier quoted context omitted.

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

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.

OS X Server uses both PHP and Ruby. From my Lion Server:

    jtm@vertex ~ $ find /usr/share -iname *.php | wc -l
         165
    jtm@vertex ~ $ find /usr/share -iname *.rb | wc -l
        5855
Even if you don't use OS X Server, Ruby.framework has been part of the API since Leopard [1], so applications can (and do) depend on it.

[1] https://developer.apple.com/library/mac/#documentation/MacOS...

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

#95

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

I appreciate the feedback, but you posted that line out of context. I did not simply provide a shortened URL without any explanation. I linked to the official Homebrew installation instructions, and provided the full URL that my bit.ly link resolves to. I also included a screenshot of the command being run with the full original URL.

What else would you suggest I do to make it less terrifying?

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

#98

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…

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.

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

#99
post #84

Earlier quoted context omitted.

Surely bundler helps solve some of these problems; at least it makes managing gems easier on a per-app basis.

And then you try and deploy it: http://serverfault.com/questions/405994/state-of-the-art-dep... And you're either stuck with this Mongrel-derived nonsense that is incapable of utilizing the computing power of the server to dynamically (de)allocate resources, requiring you to pick numbers at setup time, or you've got Passenger, which gets that right, but basically nails your deployment to one and only one Ruby. (Yes,…

It does, yes. And, to be fair, bundler has caused me a number of headaches over the years.

I guess I'm lucky in that I only need one Ruby; I can't see an easy solution for using more than one at once.

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

#100
post #59

Earlier quoted context omitted.

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.

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

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.
Post reply on HN