Ruby & Rails
W1siziisijiwmtmvmdqvmjuvmtuvndqvmzavntcxl1cxc2laaulzsw5cewiyujfzm1jwyji0dk1qqxhneth3tkm4d015ohhoetgxtvm4mu1dohhoall2wm1sc1ptsmryuv9lzjzhotlinc5qcgvnil1d-53364eba

Hendrik Mans - December 27, 2012

System-level tools are not project dependencies

DHH writes:

It’s imo an anti-pattern to have developers working on the same app use different tool chains like that. If your organization can’t decide on rvm vs rbenv, then you have deeper problems than what binstubs are checked in to your repository.

I’d like to pick up on this point, not because of the current Rails brouhaha, but because I’ve had discussions about this before and think the argument presented by DHH above and shared by many people is complete and utter nonsense.

Your Rails app has a set of dependencies, like specific gems, or even specific versions of those gems. Of course everyone on your team should use the same gem versions. Bundler solves this beautifully.

In most cases, your Rails app will require a specific version of Ruby. This, obviously, is also a project dependency, and of course everyone on your team should use the same version of Ruby. The latest version of Bundler solves this, too; also, most of the popular Ruby environment switchers out there support a .ruby-version file (ironically, the only one that doesn’t is 37signals’ own rbenv).

But here’s a couple of things that really aren’t project dependencies:

  • the tool you’re using to install and switch to a specific Ruby version
  • the tool you’re using to install native libraries (Homebrew vs. MacPorts, anyone?)
  • your operating system, or version of it
  • your preferred code editor
  • your favorite brand of shoes

Thank you, that is all.

W1siziisijiwmtmvmdkvmjuvmtuvmzgvntevmte2l2htyw5zx2j1zxjzdguyx3nxdwfyzs5qcgcixsxbinailcj0ahvtyiisijeymhgxmjajil1d-145faed7

Developer dude from Hamburg, Germany. Among other things, runs sloblog.io. Not good with descriptions. Don’t follow me on Twitter. ★

Loading comments...

Please sign in to post a comment.