Differencebetween "Rails S" and "Bundle Exec Rails S"

What is the difference between rails s and bundle exec rails s ?

Sometimes when you install a gem it comes with an executable/binary as well. Examples of these include: rails, rake, rspec, pry, etc. However, when you have multiple versions of a gem installed you then will have multiple versions of these executables sitting around. So if you want to execute one of these binaries for a given rails app you may need to disambiguate which executable you want -- the one for rake v10.1 or the one for rake v10.2, for example. Since the answer to this is discoverable by the version of the gem you have in your Gemfile.lock file (which is created by bundler), bundler supplies a command for executing a binary based on the version that is specified in the current project's Gemfile.lock. This command is bundle exec <command>.

So for most commands you'll want to run bundle exec <command> to make sure you're running the right version for your project (and also to make sure that all dependencies are also loaded from the correct versions specified in your Gemfile.lock). The one notorious exception to this rule is the rails command. The reason being that the first thing the rails command does is load up bundler and check which version of the command to execute. So you'd really just be slowing yourself down to involve bundler in the first place when running the rails command.

So, in short, use:

rails server
rails console
bundle exec <some command that isn't rails>

Rails 7 - Difference between Rails test and bundle exec rake test

The difference between those commands is from where rails is called.

Running commands with bundler allows you to execute them without having the packages installed in your system.

For example, if you don't have rails installed globally you couldn't run commands using rails directly

rails test will raise the following error:

Rails is not currently installed on this system. To get the latest
version, simply type:
$ sudo gem install rails
You can then rerun your "rails" command.

But if you run bundle exec rails test instead you should run your test suite perfectly because you're calling rails through bundle.

In your case using bundle exec rake test will ensure that you're using the same version of your Gemfile.lock.

Bundle exec rake versus rails

Two fold. As of rails 5 you can substitute rails and rake for db:migrate. What you are really changing is adding bundle exec which is telling it to execute the rake from the application's bundler instead of your platform bundler.

For instance, you have bundler v15 on your mac, and bundler v12 on the application. bundle exec rake will use bundler v12, but rake will use bundler v15.

What does bundle exec rake mean?

bundle exec is a Bundler command to execute a script in the context of the current bundle (the one from your directory's Gemfile). rake db:migrate is the script where db is the namespace and migrate is the task name defined.

So bundle exec rake db:migrate executes the rake script with the command db:migrate in the context of the current bundle.

As to the "why?" I'll quote from the bundler page:

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.

What is the difference between rails console and bundle console?

Here is a good explanation: What's the Difference Between irb, bundle exec irb, bundle console, and rails console?

irb is the basic Ruby console. It ignores your Gemfile, and only core
Ruby classes are accessible without require-ing them. It can’t easily
load gems that Bundler installs outside of RubyGems’ load path.

bundle exec irb is like irb, if you also required bundler/setup. You
can only easily require gems that are in your Gemfile.lock, but you
can load those gems no matter where Bundler put them.

bundle console is like bundle exec irb, if you also called
Bundler.require. All of the gems in your Gemfile, except the ones
marked require: false, can be used without requiring them. It’s really
convenient when you’re writing your own gems, or working on non-Rails
code.

rails console is like running bundle console inside a Rails app, if
you also required config/environment.rb. You can play with your entire
Rails app, autoloads and database connections work, and everything’s
hooked up the way you’d expect. If you’re working in a Rails app, this
is the most helpful kind of console.

Rails console vs server differences on production server

Don't you want to be starting the server in production mode using the production environment?

rails server -e production

The syntax difference between rails console environment and rails server -e environment is a bit of a PITA

Use bundle exec rake or just rake?

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.

Difference between 'bundle' and 'bundle install' rails 3?

No. install is just the default option for the bundle command. Don't run either in your Gemfile, however, just specify the gem "fubar" there -- bundler knows how to read and process that file.