Add guide for Ruby environment(s)

[daguar]

No description provided.

[migurski]

What’s the current consensus on RVM vs. rbenv?

[daguar]

Not stating a preference, but RailsBridge guides use RVM:
http://docs.railsbridge.org/installfest/osx_rvm?back=macintosh%23step2-2

For all OSs, check out RailsBridge's paths for all:
http://docs.railsbridge.org/installfest/choose_your_operating_system?back=installfest%23step3

[migurski]

Did an RVM guide, tested in Mac and Ubuntu, at Ruby-RVM.md.

[migurski]

I’d love your feedback, @invisiblefunnel—some context in issue #2.

[daguar]

Might I suggest renaming the file to Ruby.md?

It seems like RVM is an implementation detail, and unless we're thinking we'd write an rbenv approach as well, I think it's better to treat these as nice, independent, clear paths.

(Even if we do want to add instructions for rbenv, I'd probably suggest they also go inside the same Ruby.md.)

I feel like this will make it really easy for CfA devs to say, "okay, I need to link to How-To's ruby.md and rails.md" and know that these will always be up-to-date, even if the implementation for doing so (eg, rbenv) changes.

[migurski]

Sounds good. I was making it similar to the Python/Virtualenv one, but the difference is that most people already have a good-enough Python and need Virtualenv, while few people start with a sufficiently-new Ruby.

[daguar]

If we think virtualenv is a need in most Python environments, do you think we could rename that one to be Python.md? Or virtualenv.md?

I just really like the idea of clear dependency-to-name mapping (eg, "my Django app requires Python (python.md), VirtualEnv (virtualenv.md), and Django (django.md.")

And if there's a clear dependency chain, it could just be Django in the above case (and the top of the django.md file states clearly that you must first achieve python and virtualenv.)

Is this overkill? Just thinking about the most sensical dev UX.

[migurski]

I mostly agree. Ruby-RVM should be renamed Ruby, but Python-Virtualenv would stay the same because it's like a namespace? #dunno.

On Mar 13, 2014, at 9:12 AM, Dave Guarino notifications@github.com wrote:

If we think virtualenv is a need in most Python environments, do you think we could rename that one to be Python.md? Or virtualenv.md?

I just really like the idea of clear dependency-to-name mapping (eg, "my Django app requires Python (python.md), VirtualEnv (virtualenv.md), and Django (django.md.)

And if there's a clear dependency chain, it could just be Django in the above case (and the top of the django.md file states clearly that you must first achieve python and virtualenv.)

Is this overkill? Just thinking about the most sensical dev UX.

—
Reply to this email directly or view it on GitHub.

[pui]

rbenv is the new hotness, but rvm is perfectly fine. Ruby on rails recommends rbenv in turns out.

This link also has all of the instructions to get up and running with rails, although there's a bit of clicking around and digging through docs.

http://rubyonrails.org/download

[invisiblefunnel]

RVM seems to be the standard and most documented tool, but rbenv will work just as well. For more experienced developers, comfortable with Ruby dependency management, ruby-install+chruby is a strong, modular option.

Andrew Douglass and Tiffany Chu are set up with ruby-install/chruby and it has been simple enough for them so far. I'll try to document any struggles they have along the way. If it works out, I can incorporate it into this project.

Here are some more detailed thoughts on the topic: https://gist.github.com/invisiblefunnel/9538009

[migurski]

Thanks! Sounds like Andrew and Tiffany are good to go. For our purposes here, I’d like to recommend a single Ruby installation method and document only that. Where does your ruby-install/chruby method put gems? Systemwide? Local directory? Trying to understand the Virtualenv analogies.

[invisiblefunnel]

Ruby versions are installed in ~/.rubies and gems are installed in ~/.gem/ruby/<VERSION>/gems/.

$ which ruby
/Users/dannywhalen/.rubies/ruby-2.1.1/bin/ruby
$ bundle show octokit
/Users/dannywhalen/.gem/ruby/2.1.1/gems/octokit-2.7.1

[migurski]

I’d like to stick with RVM here due to its long reach. Do you foresee any incompatibilities for people developing their work under one vs. the other, or would experienced developers read “you need Ruby x.x.x” and feel confident that they could move ahead regardless of how they do it?

[invisiblefunnel]

I agree that RVM is the right choice here. As long as there is a .ruby-version file in each project there shouldn't be any issues. It's good to explicitly declare a Ruby version in the Gemfile as well (ruby 'x.y.z'). Heroku will look this up on each deploy and change the version accordingly. Ideally the .ruby-version file and the Gemfile directive always match (dev/prod parity). Here's some more reading on the origin of the .ruby-version convention.

What do folks think about having a .ruby-gemset file in each project? I'm out of the loop on this topic. It saves a setup step (choosing a gemset name) and you don't need a .rvmrc file.

Oh cool, it turns out that RVM already integrates with chruby.

[migurski]

Would .ruby-version be redundant with Heroku’s advice to put the version in the Gemfile?

You can use the ruby keyword of your app’s Gemfile to specify a particular version of Ruby.

source "https://rubygems.org"
ruby "1.9.3"
# ...

[invisiblefunnel]

Heroku doesn't check the .ruby-version file. It's just for Ruby version managers. To my knowledge, Ruby version managers don't check the Gemfile directive.

[migurski]

Thanks! Would you recommend adding a note to the Ruby file with this information?

[migurski]

@invisiblefunnel based on our conversation in the office, it sounds like the Ruby version number should exist in both .ruby-version and Gemfile, intended for different consumers. The .ruby-gemset has a lot of overlap with Gemfile and I'm not clear on the difference. Is it a thing we can avoid mentioning?

[invisiblefunnel]

These files don't need to be covered at all in a basic development setup guide. It would become relevant information for a maintainer or someone forking a project. I mentioned them earlier to inform the choice of Ruby version manager. I do think they should be a standard part of our Ruby projects, and would be happy to help document that as well. (apologies for the slow reply, I was out of the office yesterday)

[migurski]

Thanks Danny, in that case I think we can close out the ticket and call Ruby.md done-enough.