Jon Frisby

@aaronjensen: After some further testing, you're right -- git-based gems are a problem, and either binstubs, bundle exec, or rubygems-bundler + "gem regenerate_binstubs" are needed to address that.

Using a very heavy Gemfile for testing, it looks like the fastest results are produced by doing "bundle install --binstubs", and calling "bin/<whatever>", followed in distant third place by the rubygems-bundler approach, followed by bundle exec.

However, it seems to be problematic to use rubygems-bundler from the global gemset in the context of multiple per-project gemsets -- it seems the "gem regenerate_binstubs" must be done per-project. I need to look into that more and refine this protip a bit.

Thanks for the info!

@aaronjensen: I forget which gems were breaking under rubygems-bundler unfortunately, but I know some were.

I'll look at "bundle clean --force" -- the biggest problem with "gem cleanup" is if you're switching branches on a project and move BACKWARD version-wise wrt gems... I've found "rvm gemset empty" to be a handy way to approach that, but of course it slows things down like crazy when you have to do a bundle install again.

The only time I've seen bundle exec be required for a git-backed gem is when the gem stupidly tries to use Bundler to load its own dependencies. Of course it could be the case that this is the scenario in which rubygems-bundler breaks, and I'm just not remembering it...

You forgot imgur. :p

aaron: The problem with that is that it breaks with some gems, and you need to keep binstubs up to date with each project. So, you still wind up with conflicts and problems unexpectedly when you forget a step. The solution I proposed minimizes the number of manual steps involved when switching from project to project, or updating the dependencies of a project.

Again, if you like rbenv, go ahead and use it. If you don't use RVM, why are you bothering to comment here? This tip was posted for people who have need of / a preference for RVM.

rbenv doesn't even try to address things like gemsets. The attitude being that Bundler is a better way to go for that. Bundler by itself is insufficient -- it's only useful for telling you what a given project needs and is locked down to, while maintaining that information and resolving dependencies as the project evolves. It really does nothing to compartmentalize you from a polluted gem environment unless you use "bundle exec", which is awkward, annoying, and intrusive. Gemsets by themselves are insufficient as they only solve the problem of environment pollution, not version lockdown and dependency management for projects. These are solutions to two different (but related) problems.

When I saw that rbenv was punting on gem sets entirely, I pretty much flipped the bozo bit on the project, as to me it seems that they rather missed the point. It came off to me as a reactionary project by people who find overriding the cd command to be aesthetically displeasing, and are willing to contort their workflow for the sake of purity -- even if it means not solving real problems as well as they could be. The page still contains some rather amusing FUD about how "error prone" overriding the cd command is. (Yes, I'm sure it was tricky to get it right, but once Wayne did, that's not exactly code that suffers a high rate of change. To date I have never once encountered a problem from cd being overridden, and should the day come, I can always say "builtin cd <wherever>"...)

It's not "rbenv magic" I'm worried about, it's that for things to work properly, I need to generate binstubs in every project I'm working on when setting it up, .gitignore those binstubs, and have some means of ensuring my path points at the binstubs directory early (prepended rather than appended), for whichever project I happen to be working on at the moment. I could just prepend "./bin" to my path of course but that doesn't work if I cd around within a project dir (not to mention possible side effects). It's just clunky and awkward when you have 70+ projects (not an exaggeration) using a variety of rubies, and very different versions of overlapping sets of gems. This approach is simple and I don't have to worry about version hell at all. No corner-cases, no gotchas, no user-error when switching projects -- it just works.

That said, if rbenv is working well for you, great! Go ahead and use it! This snippet was not meant to incite a riot about rbenv vs RVM. It's for those who have chosen RVM and want to know how to use it effectively without having to layer on more cruft (gems, binstubs, and the like) to solve accidental byproducts of its misuse or of their misunderstandings of it.

Simple:

1) That doesn't solve all dependency muddling issues.
2) That requires mucking with the path even more. RVM already does that, so why not take advantage of what it's already doing?

Binstubs are a hack to get around a polluted gem environment.