I have seen a number of discussions on different forums about
rake. Best practice is that you run your executable scripts with
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,
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
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.
But, what if I don’t want to
Lazy? Some programmers believe it is too much extra work to prepend
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
exec you might want to consider using bundler’s binstubs. For
chruby users, you can automatically get binstubs in your
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
.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
$ alias be $
Returning nothing shows that it is free to use. Now, we would add
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 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
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.