This test would fail on default Gentoo installs as the package is executed as root.
Currently `bundle check` locks the Gemfile. According to @indirect this behaviour is intentional (see https://twitter.com/#!/indirect/status/186493694013210624). I am working on a CLI monitoring tool that makes it easier to work with cross-repository changes on projects that are split up into several repositories. This tool is supposed to display status information such as out-of-date bundler Gemfiles etc. To do so it watches the filesystem and queries for information on demand. Using `bundle check` to do so currently leads to highly confusing side-effects because suddenly the git working directory might be dirty - having changed the Gemfile.lock - because `bundle check` has been run in the background. This patch adds a boolean method option `--[no-]lock` to `bundle check` that defaults to `true` in order to not change the current behaviour but make it possible for users to turn it off. Sidenote: apparently the same behaviour also applies to `bundle show`. Am I the only one who finds this highly confusing?
From this commit on, we add a .bundlecache file inside each git/path directory in vendor/cache so we know it came from bundler. This allow us to delete those specific directories without messing with user's specific ones.
…e it, closes #1989
Signed-off-by: José Valim <email@example.com>
Conflicts: lib/bundler/source.rb spec/install/git_spec.rb
This fixes a problem which occures when you want to run `bundle` command inside code that already loads `Gemfile`. When you start a command with `bundle exec` it sets `RUBYOPT` to `-I$PATH_TO_BUNDLER -r"bundler/setup"`. Because of that, when you run the actual command it already requires bundler, which is fine, but since `GEM_PATH` was cleared on the first run `ORIGINAL_ENV` will include empty `GEM_PATH`. Now when you run `Bundler.with_clean_env`, you will not have any bundler specific env variables, but you will also not have original gem path, which will make it impossible to run any gem. To fix this I try to always keep a reference to original gem path, so it's not emptied along the way.