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
$ 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
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 website1 and also, the first paragraph of this article - why it is important to run your executables with 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
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
bundle exec in their computer’s
.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
$ alias be $
Returning nothing shows that it is free to use. Now, we would add
alias be='bundle exec' to
.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’s 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
“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.”