9e909d5be3
Update Bundler to 1.0.15. Update Rails to 2.3.12. Update rails_xss plugin. The latter two were the source of a considerable amount of grief, as rails_xss is now MUCH stricter about what string methods can be used. Also made it possible to use rake 0.9.x with Instiki. But you probably REALLY want to use ruby bundle exec rake ... instead of just saying rake ....
112 lines
4.1 KiB
Markdown
112 lines
4.1 KiB
Markdown
bundle-exec(1) -- Execute a command in the context of the bundle
|
|
================================================================
|
|
|
|
## SYNOPSIS
|
|
|
|
`bundle exec` <command>
|
|
|
|
## DESCRIPTION
|
|
|
|
This command executes the command, making all gems specified in the
|
|
`Gemfile(5)` available to `require` in Ruby programs.
|
|
|
|
Essentially, if you would normally have run something like
|
|
`rspec spec/my_spec.rb`, and you want to use the gems specified
|
|
in the `Gemfile(5)` and installed via [bundle install(1)][bundle-install], you
|
|
should run `bundle exec rspec spec/my_spec.rb`.
|
|
|
|
Note that `bundle exec` does not require that an executable is
|
|
available on your shell's `$PATH`.
|
|
|
|
## BUNDLE INSTALL --BINSTUBS
|
|
|
|
If you use the `--binstubs` flag in [bundle install(1)][bundle-install], Bundler will
|
|
automatically create a directory (which defaults to `app_root/bin`)
|
|
containing all of the executables available from gems in the bundle.
|
|
|
|
After using `--binstubs`, `bin/rspec spec/my_spec.rb` is identical
|
|
to `bundle exec rspec spec/my_spec.rb`.
|
|
|
|
## ENVIRONMENT MODIFICATIONS
|
|
|
|
`bundle exec` makes a number of changes to the shell environment,
|
|
then executes the command you specify in full.
|
|
|
|
* make sure that it's still possible to shell out to `bundle`
|
|
from inside a command invoked by `bundle exec` (using
|
|
`$BUNDLE_BIN_PATH`)
|
|
* put the directory containing executables (like `rails`, `rspec`,
|
|
`rackup`) for your bundle on `$PATH`
|
|
* make sure that if bundler is invoked in the subshell, it uses
|
|
the same `Gemfile` (by setting `BUNDLE_GEMFILE`)
|
|
* add `-rbundler/setup` to `$RUBYOPT`, which makes sure that
|
|
Ruby programs invoked in the subshell can see the gems in
|
|
the bundle
|
|
|
|
It also modifies Rubygems:
|
|
|
|
* disallow loading additional gems not in the bundle
|
|
* modify the `gem` method to be a no-op if a gem matching
|
|
the requirements is in the bundle, and to raise a
|
|
`Gem::LoadError` if it's not
|
|
* Define `Gem.refresh` to be a no-op, since the source
|
|
index is always frozen when using bundler, and to
|
|
prevent gems from the system leaking into the environment
|
|
* Override `Gem.bin_path` to use the gems in the bundle,
|
|
making system executables work
|
|
* Add all gems in the bundle into Gem.loaded_specs
|
|
|
|
### Shelling out
|
|
|
|
When shelling out (using the `system` or backticks methods,
|
|
for example), Bundler's environment changes will propogate to
|
|
the subshell environment. If you desire to shell out without
|
|
Bundler's environment changes, simply employ the `with_clean_env`
|
|
method. It will restore all environment variables to what they
|
|
were before Bundler was activated. For example:
|
|
|
|
Bundler.with_clean_env do
|
|
`brew install wget`
|
|
end
|
|
|
|
## RUBYGEMS PLUGINS
|
|
|
|
At present, the Rubygems plugin system requires all files
|
|
named `rubygems_plugin.rb` on the load path of _any_ installed
|
|
gem when any Ruby code requires `rubygems.rb`. This includes
|
|
executables installed into the system, like `rails`, `rackup`,
|
|
and `rspec`.
|
|
|
|
Since Rubygems plugins can contain arbitrary Ruby code, they
|
|
commonly end up activating themselves or their dependencies.
|
|
|
|
For instance, the `gemcutter 0.5` gem depended on `json_pure`.
|
|
If you had that version of gemcutter installed (even if
|
|
you _also_ had a newer version without this problem), Rubygems
|
|
would activate `gemcutter 0.5` and `json_pure <latest>`.
|
|
|
|
If your Gemfile(5) also contained `json_pure` (or a gem
|
|
with a dependency on `json_pure`), the latest version on
|
|
your system might conflict with the version in your
|
|
Gemfile(5), or the snapshot version in your `Gemfile.lock`.
|
|
|
|
If this happens, bundler will say:
|
|
|
|
You have already activated json_pure 1.4.6 but your Gemfile
|
|
requires json_pure 1.4.3. Consider using bundle exec.
|
|
|
|
In this situation, you almost certainly want to remove the
|
|
underlying gem with the problematic gem plugin. In general,
|
|
the authors of these plugins (in this case, the `gemcutter`
|
|
gem) have released newer versions that are more careful in
|
|
their plugins.
|
|
|
|
You can find a list of all the gems containing gem plugins
|
|
by running
|
|
|
|
ruby -rubygems -e "puts Gem.find_files('rubygems_plugin.rb')"
|
|
|
|
At the very least, you should remove all but the newest
|
|
version of each gem plugin, and also remove all gem plugins
|
|
that you aren't using (`gem uninstall gem_name`).
|