I am relatively new to Rails, and using version 3.x.I have just found out about bundle binstubs gem command which creates executable wrappers in /bin dir.Is there any benefit running commands from bin/ if there is already rake task for that.For example, I would use rake spec:models , which I prefer over bin/rspec spec/models/.
Yes.
As an example, when you install gems locally within your rails app using Gemfile and bundle install, you normally need to do a bundle exec before running tasks, so as to resolve ruby gems dependecies from the app directory, not from installed otherwise (using gem install <gemname>).
With binstubs, you don't need to do that.
Example: bundle exec rake RAILS_ENV=production onetime:generate_report without binstubs and
rake RAILS_ENV=production onetime:generate_report with binstubs
Related
I am in process of installing Redmine app via RedmineInstall documentation I try step 5 :
bundle exec rake db:migrate
then error shows :
bundler: command not found: rake
Install missing gem executables with ´bundle install´
I use redmine 3.3.0 64 for windows
I use redmine gemfile and rake was installed (i see Using rake 11.2.2)
I tried reinstall it via bundle install or gem install/uninstall, but did not help (see Successfully installed rake-11.2.2 but rake do not work).
I tried this command from ruby/bin directory or redmine directory not success.
I do not understand, that rake is successfully installed, but when i try use it with bundle it says that command not found.
The problem may be in the directory where the Redmine or rake?
Try rake db:migrate in your redmine directory without bundle exec and see if that resolves your issue.
Bundler usually provides bin stubs for rake and other gem files, so that bundle exec is not necessary or will even fail because it will look in an other gem directory where, in this case, rake might not be installed.
I really like that Spring is included in the Rails standard Gemfile now. I have a new project I started from scratch where I can just type:
rake <my rake task>
and it's run under Spring so that the whole environment doesn't have to load again.
However, I recently upgraded a project from v3.2 to v4.2.3, and I get an error. It only works if I do:
bundle exec rake
How can I get this upgraded project to run under spring again?
It seems you have system wide and application specific gem sets that conflict each other. Simply remove system wide gems and use Bundler special feature. Bundler binstubs helps to avoid prepend bundle exec every time:
gem uninstall rake
bundle install --binstubs
./bin/rake
https://github.com/sstephenson/rbenv/wiki/Understanding-binstubs
Assuming the binstubs for a project are in the local bin/ directory,
you can even go a step further to add the directory to shell $PATH so
that rspec can be invoked without the bin/ prefix:
export PATH="./bin:$PATH"
rake
Platform: windows 7, running on JRuby 1.6.8.
C:\project> rake db:migrate
rake aborted!
You have already activated rake 10.0.3, but your Gemfile requires rake 0.9.2.2.
Using bundle exec may solve this.
OK. I have added
gem "rake", "= 0.9.2.2"
to Gemfile and ran:
C:\project> bundle exec rake db:migrate
bundler: command not found: rake
Install missing gem executables with `bundle install`
<polite>WTF?</polite>
I have also done
bundle install --deployment
to no avail.
I have different versions of rake installed:
C:\project>gem list
LOCAL GEMS
...
rake (10.0.3, 0.9.2.2, 0.8.7)
How to resolve this? I need rake db:migrate working with my specific (inherited) RoR project with gems that tend to be slightly out of date, but they are all specified in Gemfile.
Don't run bundle --deployment until you clearly understand what it is used for. (it's confusing, we usually use bundle install --path vendor/bundle)
The first error means, that you should execute your command with bundle exec, like bundle exec rake db:migrate
after the version change in the Gemfile you should have just run bundle install without --deployment.
At this point I'd recommend to delete the .bundle folder in your project home, this reverses the --deployment call. Afterwards call bundle install and try it again. If it doesn't work please let us know.
Don't get frustrated, bundle is pretty cool as soon as you get the hang of it.
What is the difference between doing:
bundle exec rake
and
rake
I see people doing both, I never do bundle before my commands, curious what the reason for it is?
bundle exec executes a command in the context of the bundle.
This command executes the command, making all gems specified in the Gemfile available to require in Ruby programs.
Very useful when you have many applications with different versions of gems used
in them.
Please see docs for more information: http://gembundler.com/man/bundle-exec.1.html
bundle exec runs the command after it in the environment of Bundler. So say you had rake 0.9 in you Gemfile, but rake 10 installed in RubyGems.bundle exec rake will run rake 0.9 instead of rake 10.
I learned Rails using just the rake command like rake db:migrate; however, I read that I should be using the bundle exec rake ... instead of just plain rake. Now I'm confused about which to use.
Should I be using bundle exec rake instead of just plain rake or is it just a preference thing? Any insight would be much appreciated! Thanks!
bundle exec executes a command in the context of your bundle.
That means it uses the gems specified in your Gemfile. Much of the time, running bundle exec rake foo has the same results as if you just ran rake foo, especially if you have the same gems installed systemwide as in your Gemfile. However, some applications may specify different versions of gems than the ones you have installed systemwide, and may want those exact gems and versions to be able to run correctly. If you just run without bundle exec, you may get some weird errors.
Using bundle exec guarantees that the program is run with the environment specified in the gemfile, which hopefully means it is the environment that the creators of the program want it to be run in, which hopefully means it should run correctly no matter what weird setup you have on your computer.
It basically standardizes the environment under which the program is run. This helps avoid version hell and makes life much easier.
See http://bundler.io/v1.3/man/bundle-exec.1.html for more info.
$ bundle exec rake db:migrate
Uses the version of rake specified in the Gemfile to execute the rake task db:migrate.
But there is no rake gem specified in the Gemfile!
Yes, but a rake gem was installed as a dependency of some other gem--look in Gemfile.lock. So the rule must be: Uses the version of rake specified in Gemfile.lock.
But Gemfile.lock doesn't specify a specific version--it specifies a version greater than x.y!
Then the rule must be: Uses the version of rake that was installed in the current gemset.
$ rake db:migrate
Normally, when you issue a command on the command line, e.g. rake, your system searches for the command in the list of directories specified in your PATH environment variable. The first directory that contains the command is the version of the command that is used. To see which directory that is, you can do:
$ which rake
So if you execute,
$ rake db:migrate
that may use a different rake gem than the one you installed with bundle install. But, even if your system finds the same rake version as bundle exec, any gems required by the rake source code will be searched for in places outside your project's gemset. Therefore, there are many ways that just:
$ rake db:migrate
can screw things up.
According to the Ruby on Rails Tutorial Book(free online), section 3.6, if you are using rvm 1.11.x+ then you do not need to preface commands with bundle exec.
running any exacutable without bundle exec will have Rubygems fetching the latest version of the gem installed in your system.
By adding the bundle exec prefix instead will have the executable running in the context of your Gemfile.lock, which means that will be run using the version defined in the gem file.