summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorStephanie Morillo <rubymorillo@users.noreply.github.com>2017-07-20 11:49:50 -0400
committerGitHub <noreply@github.com>2017-07-20 11:49:50 -0400
commit9f537da2d5eaed7c1990e11d6405c392e6bc0020 (patch)
treeb8d73d876a8b15793b147ff84c1e5b4542b36b39
parent53dfec6917c9fd2795856cbd776cff2029a0416e (diff)
downloadbundler-9f537da2d5eaed7c1990e11d6405c392e6bc0020.tar.gz
Add graph re: bundle exec modifying lockfile
Hey team, I've added a graph to the documentation that explains why bundle exec makes changes to Gemfile.lock. It was originally referenced in this issue: https://github.com/bundler/bundler/issues/5245
-rw-r--r--man/bundle-exec.ronn7
1 files changed, 7 insertions, 0 deletions
diff --git a/man/bundle-exec.ronn b/man/bundle-exec.ronn
index c9ab2309e4..02cb8a1234 100644
--- a/man/bundle-exec.ronn
+++ b/man/bundle-exec.ronn
@@ -63,6 +63,13 @@ It also modifies Rubygems:
making system executables work
* Add all gems in the bundle into Gem.loaded_specs
+Finally, `bundle exec` also implicitly modifies `Gemfile.lock` if the lockfile
+and the Gemfile do not match. Bundler needs the Gemfile to determine things
+such as a gem's groups, `autorequire`, and platforms, etc., and that
+information isn't stored in the lockfile. The Gemfile and lockfile must be
+synced in order to `bundle exec` successfully, so `bundle exec`
+updates the lockfile beforehand.
+
### Loading
By default, when attempting to `bundle exec` to a file with a ruby shebang,