Hacker News Reader

Comment by masnick | Hacker News Reader

I've never found it necessary to use the --path or --binatubs options with rbenv.

For --path, I just use the default which presumably puts everything in the main rbenv folder for gems. I've never had a problem with this.

For the problem of having to type "bundle exec" before every command that uses a binary from a gem, I've heard of two alternative solutions. One is aliasing "bundle exec" to "be" or something to make it quicker to type. The other is using zsh/oh-my-zsh instead of bash and using a plugin (can't remember the name off the top of my head) that automatically figures out what should be bundle execed and takes care of it behind the scenes. I've never had trouble with this either.

View on HN

The issue with not using --path is that gems will leak between different projects, so you'll probably run in to trouble when projects depend on different versions of the same gem.

I've also used shell plugins to remedy the bundle exec issue, but they've often caused more problems than they solve. I'd much rather just stick something in my PATH than use shell plugins.

I find it much easier to simply explicitly require a specific version in my Gemfile if I'm having trouble with a gem, rather than having the extra overhead of managing multiple sets of gems.

I think it's a more correct solution as well. You won't have any guarantees that Bundler will resolve the dependencies correctly in production when it doesn't in your development environment.

That's also a good approach. The moving the bundler binstubs to a central location would work nicely as well, I imagine.

Absolutely.

I'm using oh-my-zsh with the bundler plugin, which aliases all binstubs to a function that prepends bundle exec if there's a Gemfile. It works very well in practice. rbenv handles the correct ruby version, Bundler loads the right gem, and it all falls back to the newest version on the system default ruby.

It's a few more moving parts behind the scenes than I'd prefer, but once configured it's completely transparent.

Isn't this solved by storing Gemfile.lock? I thought that was the whole purpose of that file..

Reply on news.ycombinator.com