| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
|
|
| |
Add TODO to change to warn in 2.0
`dup` string for old rgv
`dup` string for old rgv
|
|
|
|
|
|
| |
Reorganize specs
Remove whitespace
|
|
|
|
| |
Remove space
|
| |
|
|\
| |
| |
| | |
Version 1.13.0.rc.1
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
[LockfileParser] Support for old RG on Ruby 2.3+
Fixes #4698
\c @allenzhao
(cherry picked from commit 78d614413a994b5acd3dccd82b0782290d0d850d)
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Unset GEM_PATH with nil not empty string.
This should fix #4592, the tests all pass, but the line of code in
question goes back to 2010, so this sorta seems slightly dangerous, but
it's probable the circumstances of hitting this line in conjunction with
`bundle exec` is a combination that didn't exist prior to 1.12.x.
Issue #4592 has a full diagnosis, but the gist of it is this: if an
empty string is passed as the `GEM_PATH` to the subsequent process
launched by `bundle exec`, then if the `cmd` portion of `bundle exec` is
a ruby shebanged file, then if the current bundle install uses a local
path (`disable_shared_gems` is true) then it won't be able to find the
bundler gem at all because Bundler doesn't install itself into its own
Bundle, it's only installed in the system gems for the Ruby.
`nil` must be passed because the RubyGems code that sets up the
`GEM_PATH` does a conditional on the current `GEM_PATH` and empty string
evaluates to true, whereas `nil` evaluates to false. In the false case
the `GEM_PATH` is internally populated with the system gems path such
that the bundler gem can be found.
(cherry picked from commit 37064b3a900475e684dd090d332b88d4c888c128)
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add machinery for printing major deprecations
First step towards handling all of #4695
\c @RochesterinNYC @indirect
(cherry picked from commit dca6d26833ddd9d9de658bef7274c8fa21014c44)
|
| |
| |
| |
| |
| |
| |
| |
| | |
[Definition] Add a #change_reason printed in debug
@indirect this might make your debugging a bit easier?
(cherry picked from commit 378602f073f808046741a829903d6ea6104f619a)
|
| |
| |
| |
| |
| |
| |
| |
| | |
Prefer spec name matches when searching for an exe
Closes #4705.
(cherry picked from commit d497e04e336fcb54f6f92acbb6665b84d11ca396)
|
| |
| |
| |
| |
| |
| | |
[Trampoline] Dont change the load path just for postit
(cherry picked from commit bacb0e7835996df44681f84bf662dbe0fb9deb30)
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Don't incorrectly relativize sibling `--path` with the same prefix
Given current working directory `/foo/app`, when you install with
`--path /foo/app_cache`, ensure that the messaging says:
Bundled gems are installed into /foo/app_cache
instead of the incorrect:
Bundled gems are installed into ._cache
(cherry picked from commit 3b928d83c1b606b4598c6662528b20482762a14d)
|
| |
| |
| |
| |
| |
| |
| |
| | |
[Definition] Just search for changed specs in an exactly matching source
\c @indirect
(cherry picked from commit faf82ccc97ab2441bd4fe849d12151fb347a81cf)
|
| |
| |
| |
| |
| |
| | |
[GitProxy] Deinit submodules if they are not requested
(cherry picked from commit 5e88c8d494d40157dd1ec9b34be8aafe68431a90)
|
|\ \
| | |
| | |
| | | |
[GitProxy] Deinit submodules if they are not requested
|
| | | |
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | | |
[Definition] Just search for changed specs in an exactly matching source
\c @indirect
|
| |/ / |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Don't incorrectly relativize sibling `--path` with the same prefix
Given current working directory `/foo/app`, when you install with
`--path /foo/app_cache`, ensure that the messaging says:
Bundled gems are installed into /foo/app_cache
instead of the incorrect:
Bundled gems are installed into ._cache
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Given current working directory `/foo/app`, when you install with
`--path /foo/app_cache`, ensure that the messaging says:
Bundled gems are installed into /foo/app_cache
instead of the incorrect:
Bundled gems are installed into ._cache
|
|\ \ \
| | | |
| | | |
| | | | |
[Trampoline] Dont change the load path just for postit
|
| | | | |
|
|\ \ \ \
| |_|/ /
|/| | |
| | | |
| | | |
| | | | |
Prefer spec name matches when searching for an exe
Closes #4705.
|
| |/ / |
|
| | | |
|
|/ /
| |
| |
| | |
This could cause definition to think bundler is being updated
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
Will make future diffs much easier to read
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Unset GEM_PATH with nil not empty string.
This should fix #4592, the tests all pass, but the line of code in
question goes back to 2010, so this sorta seems slightly dangerous, but
it's probable the circumstances of hitting this line in conjunction with
`bundle exec` is a combination that didn't exist prior to 1.12.x.
Issue #4592 has a full diagnosis, but the gist of it is this: if an
empty string is passed as the `GEM_PATH` to the subsequent process
launched by `bundle exec`, then if the `cmd` portion of `bundle exec` is
a ruby shebanged file, then if the current bundle install uses a local
path (`disable_shared_gems` is true) then it won't be able to find the
bundler gem at all because Bundler doesn't install itself into its own
Bundle, it's only installed in the system gems for the Ruby.
`nil` must be passed because the RubyGems code that sets up the
`GEM_PATH` does a conditional on the current `GEM_PATH` and empty string
evaluates to true, whereas `nil` evaluates to false. In the false case
the `GEM_PATH` is internally populated with the system gems path such
that the bundler gem can be found.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This should fix #4592, the tests all pass, but the line of code in
question goes back to 2010, so this sorta seems slightly dangerous, but
it's probable the circumstances of hitting this line in conjunction with
`bundle exec` is a combination that didn't exist prior to 1.12.x.
Issue #4592 has a full diagnosis, but the gist of it is this: if an
empty string is passed as the `GEM_PATH` to the subsequent process
launched by `bundle exec`, then if the `cmd` portion of `bundle exec` is
a ruby shebanged file, then if the current bundle install uses a local
path (`disable_shared_gems` is true) then it won't be able to find the
bundler gem at all because Bundler doesn't install itself into its own
Bundle, it's only installed in the system gems for the Ruby.
`nil` must be passed because the RubyGems code that sets up the
`GEM_PATH` does a conditional on the current `GEM_PATH` and empty string
evaluates to true, whereas `nil` evaluates to false. In the false case
the `GEM_PATH` is internally populated with the system gems path such
that the bundler gem can be found.
|
| | | |
|
| |/
|/| |
|
| | |
|
|\ \
| | |
| | | |
Update vendored Molinillo to 0.5.0
|
| | | |
|
| | | |
|
|\ \ \
| | | |
| | | | |
do not log the credentials used to contact a gem server
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Adds a filter_uri method to HTTPError backed by the
URICredentialsFilter to be used when preparing error output.
In the tests, replace a double object with a real URI and
change a test hostname to be valid so that older versions of
Ruby's URI module don't choke on it. It would be cool to somehow
replace this work with the `anonymized_uri` in the
Bundler::Source::Rubygems::Remote class.
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Previously, we'd wrongly conclude there are no path changes when there are
changes. We'd parse the Gemfile.lock and compare the source.specs, the
gemspecs currently in the path, to what's in the Gemfile.lock's locked.specs.
Unfortunately, locked.specs for Path sources creates an Index with the specs
from the filesystem and NOT what we already parsed from the Gemfile.lock! In
other words, we compare the filesystems specs for a path to itself and always
conclude "No changes detected!"
Instead, we build an index with specs for the source we want from the
already parsed Gemfile.lock. We use this index to compare to the current
source.specs index from the filesystem.
Ironically, this issue was masked by the bug from our prior fix, namely that
dependencies_for_source_changed? always would conclude that there were changes.
Because of that bug, it would short circuit out of the nothing_changed? method
and force a re-resolve with path gems, which would properly build the
Gemfile.lock from the prior parsed one.
Undo some test changes needed to get the first fix to pass.
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
- For comparing source dependencies to locked source dependencies
- For comparing two Bundler::Index dependencies
Added test case.
Fixed bad tests cases hidden by the above bug:
- 'foo' depended on rack but we didn't build 'rack' in the path
- We couldn't find 'bar' built into 'foo/bar' because the :path only had 'foo'
|