Hacker Newsnew | comments | show | ask | jobs | submit login

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

-----




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: