But I Don't Want to `bundle exec`

I have seen a number of discussions on different forums about bundle exec rake vs rake. Best practice is that you run your executable scripts with bundle exec.

Recently when running rake on a project I’d just joined, I ran into an odd error related to different versions of gems being activated. However, RubyGems was friendly enough to suggest a potential solution to my problem: use bundle exec.

$ rake
rake aborted!
Gem::LoadError: You have already activated rake 10.4.2, but your Gemfile requires rake 10.4.0. Prepending `bundle exec` to your command may solve this.

Before taking up the suggestion, I checked the Gemfile and found that the rake version specified was different from the one installed systemwide. So I ran rake once again, this time with bundle exec prepended.

$ bundle exec rake
...............................................

47 examples, 0 failures

Troubleshooting

Moving forward, I thought I needed to know the exact rake version that was used to execute the test tasks. Running rake --version gives the version of the rake install systemwide. So I ran it…

$ rake --version
rake, version 10.4.2

This is the systemwide version of rake installed. Running it again with bundle exec prepended gave the version of the rake specified in the app’s Gemfile.

$ bundle exec rake --version
rake, version 10.4.0

This confirms what has been stated on bundler’s website¹ and also, the first paragraph of this article - why it is important to run your executables with bundle exec.

But, what if I don’t want to bundle exec?

Lazy? Some programmers believe it is too much extra work to prepend rake every time with bundle exec. Well, it’s not a bad thing to be a lazy programmer. The benefit of being lazy is that you get things done in the smartest, shortest way possible. This is because you tend to avoid doing too much.

So as lazy as you want to be, if you want to run rake without typing bundle exec you might want to consider using bundler’s binstubs. For rbenv and chruby users, you can automatically get binstubs in your $PATH by running mkdir -p .git/safe && export PATH=".git/safe/../../bin:$PATH" while rvm users can follow the steps in our prior blog post. This means after integrating binstubs, you won’t have to type bundle exec ever again.

Another thing developers do is to set an alias for bundle exec in their computer’s .bash_profile or .zshrc for zsh. If you want to go with the alias method, before you set the alias for bundle exec, check if the alias you want use has not been set for another command. Running alias <your_alias> in zsh returns the command set for the alias if it already exist. In our case let’s check for be.

$ alias be
$

Returning nothing shows that it is free to use. Now, we would add alias be='bundle exec' to .bash_profile or .zshrc and run our executables with be prepended to the commands just like this: be rake. You can load the edited file to the current shell session by running source .zshrc or restart your shell session to reload the file - opening a new tab or window should do.

$ be rake
...............................................

47 examples, 0 failures

Whether you use binstubs or alias method, you can now eliminate extra mental effort by running your executable without explicitly preprending the command with bundle exec.

Footnotes

1.

In some cases, running executables without bundle exec may work, if the executable happens to be installed in your system and does not pull in any gems that conflict with your bundle. However, this is unreliable and is the source of considerable pain. Even if it looks like it works, it may not work in the future or on another machine.