Hacker News Reader

Comment by javajosh | Hacker News Reader

Thanks. I'm not really a rails person, so forgive me if I have some questions. Am I correct in interpreting that thread as DHH not wanting to support multiple ruby package managers in the rails codebase? In particular, DHH has 'blessed' rbenv and that commit wants to support rvm?

If this is the case, then I have to wonder: why is there any dependency on a package manager at all in the rails codebase? This just seems odd to me, and perhaps is the source of the conflict. E.g. people are fine with 'omakase' frameworks, but these menus typically don't include toolchain dishes. It would be like going into a restaurant and being told that you must use chopsticks, no forks allowed.

View on HN

> In particular, DHH has 'blessed' rbenv and that commit wants to support rvm?

No. Two things are going on:

1. 'binstubs' will now be checked into source control. If I use MRI and you use JRuby, they'll start with different things, and therefore, cause conflict.

2. Many of the Ruby version switchers work with '#!/usr/bin/env ruby', but rbenv won't in certain circumstances, so an optimization for it has been built into the framework now.

David maintains that if I use MRI and you use JRuby, or if I use rvm and you use rbenv, this is an 'organizational failure.'

"Many of the Ruby version switchers work with '#!/usr/bin/env ruby', but rbenv won't in certain circumstances, so an optimization for it has been built into the framework now."

Incorrect. It is support for an enhancement that rbenv provides.

You often want to invoke an application binstub from another program such as cron, and you want to use the per-project Ruby version specified in the application's root directory. Other version managers require you to spawn a subshell and load the version manager into the shell or otherwise set up the per-project Ruby version environment, then `cd` into the application directory, and finally run the binstub.

rbenv requires an environment set-up step too—set `RBENV_DIR` to the application root—but provides a wrapper that eliminates the need for such gymnastics. When you change a binstub's shebang to `#!/usr/bin/env ruby-local-exec` rbenv automatically searches up the binstub's directory tree to find the right Ruby version.

Thank you for clarifying the exact circumstances, Sam. I don't use rbenv, I was going by discussions on the ticket and in Campfire. I was referring to that difference in the binstub, but maybe should have been more clear that that's a conflict with the enhancement and not the base features of rbenv.

If a team is using different versions/runtimes of ruby I would have to agree this is an organizational feature in some cases. If you're working on a webapp you should be aiming to make as few differences between a development box & production as possible. Its unlikely that you have jruby & mri in production, wherein lies the failure.

Square is one example of a company which famously develops in MRI but deploys JRuby to production.

That sounds crazy to me, but I have very little experience with ruby. In PHP/python doing that can be unpleasant.

Reply on news.ycombinator.com