I mistakenly created my databases using rake db:create:all without including bundle exec. Should I remove all the databases and recreate them using bundle exec rake db:create:all?
bundle exec rake db:create:all executes the rake script with the command db:create:all in the context of the current bundle.
In some cases, running executables(like db:create:all) without bundle exec may not work, if the executable is not installed in your system or pulls in any gems that conflict with your bundle.
But since in your case, it worked fine without returning any errors, removing and recreating databases is not required.
Related
What is the difference between using bin/rake and bundle exec rake.
And which is one preferred style?
bin/rake db:migrate
bundle exec rake db:migrate
bundle exec executes a command in the context of your application.
As each application can have different versions of gem used. Using bundle exec guarantees that you use the correct versions.
I use bundle exec always instead of rake because i have multiple applications running on my system.
Try to use bundle exec rake db:migrate always.
You can learn more about it here Official documentation
bin/rake is a kind of stub for the rake command from bundled Gems. It has exactly the same function as bundle exec rake. See http://bundler.io/v1.14/man/bundle-install.1.html and search for binstubs for more about stub. And also note that bin/rake and bin/rails are stubs generated by Rails, which are different in code from the stubs generated by bundler. However, they all serve the same purpose and have the same function.
You have 3 options on a typical system:
bin/rake db:migrate
rake db:migrate
bundle exec db:migrate
The first option is simply calling the path to the rake program, whose launcher can be found in the hidden /bin folder. This launcher is usually just a symlink to the program's content found in your /.rvm directory. You can find its original location by executing $ which rake, which will give you something like /home/ubuntu/.rvm/gems/ruby-2.2.3-p481#devonzuegel/bin/rake.
By default, the second option is essentially the same as the first on most systems. It's what is called an alias, which is basically just a shorthand command for some other program. This is defined somewhere in your shell settings as something like alias rake='/bin/rake'. It's possible that this alias is pointed to a different program on your machine though, so check that before taking my word for it.
When you use bundle exec you're telling bundler to ensure that only the gems and their specified versions from your Gemfile.lock are loaded. This will only work if you're in a directory that contains a Gemfile.lock or whose parent/grandparent directory contains one.
When I do rake db:migrate, I get the following error:
rake aborted!
Gem::LoadError: You have already activated rake 10.2.2, but your Gemfile requires rake 10.1.0. Using bundle exec may solve this.
How can solve this?
This error is due to the fact that some applications may specify different versions of gems than the ones you have installed.
Try using bundle exec rake db:migrate.
Using bundle exec guarantees that the program is run with the environment specified in the gemfile.
Perhaps:
bundle exec rake db:migrate
There might be other gems in the Gemfile which are dependent on rake 10.2.2, while you are trying to install rake 10.1.0 via your gemfile or explicitly mentioned it. A look into your Gemfile will help.
In case you have specific environment, you may want to run
bundle exec rake db:migrate
to make sure you are running it appropriately.
As per another answer given on this topic, you can also try deleting the Gemfile.lock file and re-running bundle install to regenerate the Gem dependencies.
After this error in my web page when i have run > rake db:migrate. It shows error such as:
rake aborted!
you have already activated rake 10.1.1 but you gemfile requires rake 10.1.0 using bundle exec may solve this.
when i tried with bundle exec rake db:migrate it works.
And when i tried with the rake db:migrate. i shows error
My question is:
What is the difference between bundle exec rake db:migrate and rake db:migrate.
every time i have to do like this if yes then why?
What is the problem in my project.
Thanks.
bundle exec rake db:migrate will run rake db:migrate with the environment of your Gemfile.
You have an error because your Gemfile requires a version of rake but you have a newer one installed on your system.
By default, rake will run the latest available version, hence the mismatch.
You should always prefix your commands with bundle exec inside a project managed by bundler, I personally alias bx to bundle exec.
You can also use binstubs
Try to run bundle update.
It seems, that your Gemfile.lock is out of sync with your Gemfile.
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.