| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| | |
[Definition] Add a #change_reason printed in debug
@indirect this might make your debugging a bit easier?
|
| | | |
|
| |/
|
|
| |
This could cause definition to think bundler is being updated
|
| |\
| |
| |
| |
| |
| |
| |
| | |
Add machinery for printing major deprecations
First step towards handling all of #4695
\c @RochesterinNYC @indirect
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/
|
|
| |
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.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
[LockfileParser] Support for old RG on Ruby 2.3+
Fixes #4698
\c @allenzhao
|
| |/ / |
|
| |\ \
| | |
| | |
| | | |
Change Rakefile to work as a RubyGems submodule
|
| | | | |
|
| |/ / |
|
| |\ \
| | |
| | |
| | | |
Fix hardcoded bundler version string in trampoline specs
|
| |/ / |
|
| |\ \
| | |
| | |
| | | |
Version 1.13.0.pre.1
|
| |/ / |
|
| |\ \
| | |
| | |
| | |
| | |
| | | |
[Docs] Add update --bundler
\c @indirect
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | | |
[Docs] Remove descriptions in brackets inside gemfile.5.ronn
|
| | |/ / |
|
| |\ \ \
| | | |
| | | | |
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.
|
| |\ \ \ \
| |/ / /
|/| | | |
[WIP] Properly detect path spec changes to avoid needless re-resolve
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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'
|
| |\ \ \
| |/ /
|/| | |
[RubygemsIntegration] Allow redefining private methods
|
| |/ / |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
[bundle] Automatically trampoline to postit
- [x] Specs
~~Except on bundle exec, since that would be too slow~~
~~If you want, I guess we could vendor postit and manually setup the `LOAD_PATH` and `-r` the full path to the vendored postit exe. Your call.~~ Done this
\c @indirect
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
