I have seen a number of discussionson different forums about bundle exec rakevs rake. Best practice is that you run your executable scripts with bundle exec.
Recently when running rakeon a project I’d just joined, I ran into an odd error related to different versions of gems being activated. However, RubyGemswas friendly enough to suggest a potential solution to my problem: use bundle exec.$ rakerake 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 execprepended.$ 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 --versiongives the version of the rake install systemwide. So I ran it…$ rake --versionrake, version 10.4.2
This is the systemwide version of rake installed. Running it again with bundle execprepended gave the version of the rake specified in the app’s Gemfile.$ bundle exec rake --versionrake, version 10.4.0
This confirms what has been stated on bundler’s website 1and 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 rakeevery 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 rakewithout typing bundle execyou might want to consider using bundler’s binstubs. For rbenvand chrubyusers, you can automatically get binstubs in your $PATHby running mkdir -p .git/safe && export PATH=".git/safe/../../bin:$PATH"while rvmusers can follow the steps in our prior blog post. This means after integrating binstubs, you won’t have to type bundle execever again.
Another thing developers do is to set an aliasfor bundle execin their computer’s .bash_profileor .zshrcfor 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_profileor .zshrcand run our executables with beprepended to the commands just like this: be rake. You can load the edited file to the current shell session by running source .zshrcor 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 binstubsor aliasmethod, you can now eliminate extra mental effort by running your executable without explicitly preprending the command with bundle exec.