| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Woraround for https://github.com/travis-ci/travis-ci/issues/8892
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Allow test execution in paths containing dash.
PR #5036 added restriction on what characters can be contained in path,
from where the specs are executed. But they dissallows even dash, which
is hopefully handled just fine on all systems.
This patch fixes #6185 by relaxing the restriction a bit and allowing
path to contain dash.
(cherry picked from commit 5566b687c135178561f7524d3a5cb68fee56e416)
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Stop overriding specs during double-checks
This fixes my test-case reproduction of #6072. I’m pretty sure it’s because
the double-check was overriding the locally installed index specs with
specs fetched from the RubyGems API, causing Bundler to conclude that the
gems aren’t installed, even though they are.
@deivid-rodriguez @y-yagi can you verify that this patch fixes the issues with `inline` that you were seeing?
(cherry picked from commit 953acf7eb7c27f8fb569713c5276e12561687d6d)
|
| |
|
|
|
|
|
|
|
|
|
| |
Be more precise when replacing Bundler version in lock file.
Lets say the current Bundler version is 1.16.0. If the test suite is, by a chance, executed in directory which contains such version string, this path is stored in Gemfile.lock file. Later, the test tries to replace
the version of Bundler in the lock file, but instead, it replaces the version in path. Be more careful what should be actually replaced.
This is related to #6185 although it does not resolve the original concern.
(cherry picked from commit 6cef06d19fa04e2cee5ff5faba82e98c08f08d13)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bail out of reducing depency trees on huge dependency conflict sets
### What was the end-user problem that led to this PR?
The problem is described in #6114 - An unusually large set of conflicting dependencies leads to bundler get stuck and lead to very unhealthy amounts of memory and CPU time be consumed.
### What was your diagnosis of the problem?
This happens because because a too large array is fed into Array#combination in the "reduce_trees" lambda in `version_conflict_message`.
### What is your fix for the problem, implemented in this PR?
By simply bailing out when the conflict set is bigger than a certain size,
we'll get a result that is similar to what happened in earlier bundler versions
but skip a ton of CPU cycles and memory allocations.
I've chosen the limit rather unscientifically by playing around with the result
set sizes. 15 seems to be a good compromise but really anything larger than 10
should work (and with work I mean "should not usually not have to be invoked").
### Why did you choose this fix out of the possible options?
Reducing the conflict trees has been a rather new addition to bundler, so defaulting back to the old behavior of not reducing the trees seems like an OK option. It may be possible to also optimize the reduction algorithm, but since this is very much an edge case that only happens when using Bundler slightly out of the normal procedures, I think a simple bail out is sufficient.
(cherry picked from commit fc341ed6e87b324a55719b2145f6fd6576067477)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Let users generate gemfiles inside paths whos parent contains a Gemfile
### What was the end-user problem that led to this PR?
Users are unable to generate a new Gemfile with `bundle init` if there is a Gemfile in any
parent folder.
Closes #6205
### What is your fix for the problem, implemented in this PR?
Don't use `SharedHelpers.default_gemfile` as that searches up the paths for a Gemfile. Instead only check the current directory.
|
| |\
| |
| |
| |
| |
| | |
Prepare to release v1.16.1
I picked merge commits targeted v1.16.1 from https://github.com/bundler/bundler/milestone/56 .
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Show warning message about binstub outside generation.
/cc @indirect
Fixes #6149.
Originated from https://github.com/bundler/bundler/issues/6149#issuecomment-347783823
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Setup custom Gemfile path before loading bundler for binstubs
### What was the end-user problem that led to this PR?
While you have several gemfiles: `Gemfile` and `Gemfile.tools`.
and generates binstubs for gems from second gemfile: `BUNDLE_GEMFILE=Gemfile.tools bundle binstubs rubocop`
when you invoke those bin `bin/rubocop`
then you see error like:
```bash
/usr/local/opt/rbenv/versions/2.4.2/lib/ruby/gems/2.4.0/gems/bundler-1.16.0/lib/bundler/rubygems_integration.rb:458:in `block in replace_bin_path': can't find executable rubocop for gem rubocop. rubocop is not currently included in the bundle, perhaps you meant to add it to your Gemfile? (Gem::Exception)
from /usr/local/opt/rbenv/versions/2.4.2/lib/ruby/gems/2.4.0/gems/bundler-1.16.0/lib/bundler/rubygems_integration.rb:489:in `block in replace_bin_path'
from bin/rubocop:21:in `<main>'
```
### What was your diagnosis of the problem?
When you have generated `bin/bundler` by rails or by `bundler` it has setup of `BUNDLE_GEMFILE` by default as `Gemfile` or by gemfile which has been setup on `bundle binstub bundler`.
So your binstub for rubocop could not change it.
### What is your fix for the problem, implemented in this PR?
I propose to use`BUNDLE_GEMFILE` from gem's binstub over bundler's binstub version
### Why did you choose this fix out of the possible options?
This was default behavior before #5878 introduced. Just added some fix to related PR.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Ignore to generate documentation of templates.
### What was the end-user problem that led to this PR?
When users invoke `rdoc -o rdoc lib`, it generates documentation contains template files under the `lib/bundler/template` like `rdoc/lib/bundler/templates/newgem/bin/setup_tt.html`
These files are not useful for users.
### What is your fix for the problem, implemented in this PR?
I added `.document` file to its directory.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Stop overriding specs during double-checks
This fixes my test-case reproduction of #6072. I’m pretty sure it’s because
the double-check was overriding the locally installed index specs with
specs fetched from the RubyGems API, causing Bundler to conclude that the
gems aren’t installed, even though they are.
@deivid-rodriguez @y-yagi can you verify that this patch fixes the issues with `inline` that you were seeing?
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Include bundler.gemspec in the gem because warbler breaks w/o it
f06405 caused a regression with warbler, described in #6165 and jruby/warbler#421
If the fix is ok, it should probably be cherry-picked to 1-16-stable.
### What was the end-user problem that led to this PR?
Upgrading from bundler v1.15.x to v1.16.0 causes warbler to break/abort with error.
### What was your diagnosis of the problem?
1. error message from warbler: missing file
2. see why file is missing
3. google to see if it's just me 😄
### What is your fix for the problem, implemented in this PR?
Put the missing (from warblers point of view at least) back.
### Why did you choose this fix out of the possible options?
Seems easier than to fix warbler.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
r=indirect
Resolver: treat dependencies with prerelease versions as slightly constrained
Fixes https://github.com/bundler/bundler/issues/6181.
In Bundler 1.15.4, the way we checked for pre-releases meant that dependencies with a lot of them sorted as more constrained than those with few/none. When we moved to our updated resolution strategy in 1.16.0 we accidentally lost that behaviour.
I'm not wild about this PR, but it fixes the resolver regression. It's unsatisfying because it would be nice to believe the resolver will always resolve performantly, regardless of the sort order thrown at it, but clearly that isn't the case.
Conceptually, this can be justified as "when two resolutions are possible, we prefer the one that does not require one dependency to be at a pre-release version".
If others are happy with this I can write a test for it.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
r=indirect
Fix NoMethodError during `bundle update --group`
### What was the end-user problem that led to this PR?
#6156: NoMethodError: undefined method `version' for nil:NilClass
### What was your diagnosis of the problem?
The `bundler` gem does not participate in the lockfile, but it can still be included in the list of dependencies that are being updated by `bundle update` if `--group` is specified.
For example, if a Gemfile contains `bundler-audit` (which depends on `bundler`) in the `:development` group, then updating with the option `--group=development` will naturally include `bundler` in the list of gems to evaluate for updating.
The trouble is that since `bundler` is excluded from the lockfile, searching the locked gems for a gemspec for bundler will return `nil`. This caused the following error during `bundle update`:
NoMethodError: undefined method `version' for nil:NilClass
### What is your fix for the problem, implemented in this PR?
This PR solves this bug by skipping over gems (i.e `bundler`) that are not in the lockfile when comparing gem versions at the conclusion of the upgrade command.
Fixes #6156.
### Why did you choose this fix out of the possible options?
I chose this fix because the bug seems to have been introduced by 618c09b59d1318958c23b1b0031c68c93186851a. My fix takes place within the new feature that was added in that commit, so it seems safe and unlikely to have side-effects.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Rename .travis.yml.tt to travis.yml.tt.
### What was the end-user problem that led to this PR?
An installer of ruby core ignored dotfiles. and it is an inconsistency with gitignore file.
So bundled bundler fails `bundle gem` commands caused by this file.
This commit was r60122 from ruby/ruby: https://github.com/ruby/ruby/commit/5b3d137b1fd9f9f56fa6f17888ab8038906ed760
https://github.com/ruby/ruby/pull/1710
|
| |/
|
|
|
|
|
|
|
|
|
|
|
| |
Use helper methods for relative path references in the specs
Ruby core needs to change `Spec::Path.root` and gemspec, bin, spec directories structure.
1. I changed spec directory from `spec` to `spec/bundler` because ruby core has rubyspec files under the `spec/rubyspec`.
2. I changed gemspec location to `bundler.gemspec` to `lib/bundler.gemspec`.
ref. https://bugs.ruby-lang.org/issues/12733#note-15
This pull request make we can modify root, gemspec path to flexible locations. After merging this pull request, I will add directory structure of ruby core repository to only `spec/support/path.rb`
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fixed failing examples with Ruby 2.5.
(It targets 1-16-stable branch. I will create another pull request for master)
It's introduced by `URI::Generic` changes.
see https://github.com/ruby/ruby/commit/ed48bfa5e8770a345424abd7f24f94ea9bbf5973
I added a hostname to examples that expect `file:` string in result messages.
|
| | | |
|
| | |
| |
| |
| |
| | |
It's introduced by URI::Generic channges.
https://github.com/ruby/ruby/commit/ed48bfa5e8770a345424abd7f24f94ea9bbf5973
|
| |\ \
| |/
|/|
| |
| |
| | |
Rename `-rubygerms` option.
Followup #6080 for 1-16-stable branch.
|
| |/
|
|
|
|
|
| |
remove it.
Picked r60125 from ruby/ruby:
https://github.com/ruby/ruby/commit/9de6c712b66aad77df40661c1fc6d37e9a5c251a
|
| |\
| |
| |
| |
| |
| | |
Fix broken status on Travis CI
In Dec 2017, 1-16-stable branch of Travis was broken caused outside condition. I try to fix it.
|
| |/
|
|
|
|
|
|
| |
* spec_helper.rb: Remove/Restore bundler files as default gems. It conflicts with some examples.
* bundler/fetcher_spec.rb: Use dummy certification file instead of mock object. Because `File.read`
was called with `bin/rspec` for gemspec loading.
* support/buidlers.rb: An argument of `build_spec` conflicts some old versions of rubygems.
* support/rubygems_ext.rb: Order gem dependency for Ruby 1.8.7-2.2.2
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r=colby-swandale
Ensure that autoloads are resolved in the real working directory
Fixes an issue on 2.5.0-dev where using local git overrides would cause an exception because the default bundler had been loaded
### What was the end-user problem that led to this PR?
The problem was Bundler was failing 8 specs against ruby trunk.
### What was your diagnosis of the problem?
My diagnosis was when the autoload for `URICredentialsFilter` fired in a `chdir` block, the default bundler gem was getting activated.
### What is your fix for the problem, implemented in this PR?
My fix eagerly trips that auto-load in the git proxy.
### Why did you choose this fix out of the possible options?
I chose this fix because it's a one-liner.
(cherry picked from commit ccc5d6130c68c6989a2553f454d2d5d67caff025)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Update vendored Molinillo to 0.6.4
### What was the end-user problem that led to this PR?
The problem was uncovered in #6114.
### What is your fix for the problem, implemented in this PR?
My fix updates molinillo to 0.6.4.
### Why did you choose this fix out of the possible options?
See https://github.com/CocoaPods/Molinillo/releases/tag/0.6.4 for release notes.
(cherry picked from commit b20214d10ac9883eb54b7c08bdeb3e2724bc018e)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prioritise explicitly requested gems in dependency resolution sort order
### What was the end-user problem that led to this PR?
Calling `bundle update github-pages` on https://github.com/Floppy/cv was causing a downgrade in the `github-pages` version.
### What was your diagnosis of the problem?
The `Bundler::Resolver#sort_dependencies` method didn't have any logic to prioritise explicitly requested gems. Therefore, where two rival resolutions were possible (in this case one with `activesupport` at 5.1.4 and `github-pages` at 24, and one with `github-pages` at 166 and `activesupport` at 4.2.9), Bundler didn't always correct the most desirable resolution.
### What is your fix for the problem, implemented in this PR?
My fix is to explicitly prioritise requested gems in the dependency sort order during resolution.
### Why did you choose this fix out of the possible options?
I chose this fix because it's intuitive.
(cherry picked from commit 23316ffeafa83b460a86da95e51b3704c6faec12)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Avoid activating stdlib digest under Ruby 2.5
The problem was, under ruby 2.5, Bundler would activate digest, which is now a stdlib gem, preventing users from choosing a different version.
With this change, the travis build against trunk should go green, hopefully.
My diagnosis was we needed to lazy-load digest.
My fix removes all `require "digest"` top-level statements from the Bundler codebase, and replaces the top-level `Digest` method with one that will `require "digest"`.
I chose this fix because it would keep the use of digest classes thread-safe.
\c @hsbt
(cherry picked from commit b9c12ee67661581f8a4fb5f47a375b5c7da2ed1e)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Avoid bundle exec rescue of SignalException
Avoid rescue of SignalException in kernel_load and with_friendly_errors This allows SignalException to be handled gracefully by the ruby interpreter.
This supersedes #6091.
### What was the end-user problem that led to this PR?
Fixes #6090
### What was your diagnosis of the problem?
CLI::Exec#kernel_load should not rescue the SignalException. Neither should with_friendly_errors, so it unwinds all the way to the ruby interpreter.
### What is your fix for the problem, implemented in this PR?
Two rescue and re-raises specific to SignalException.
### Why did you choose this fix out of the possible options?
My first naive attempt was #6091, where I had missed the outer rescue in with_friendly_errors, all of the other special friendly error behavior, and the spec dependencies. While I still suspect that kernel_load and friendly_errors might be rescuing/handling more than they should (for comparison: binstub doesn't do this) this is a much more minimal, safer, and easier fix to #6090.
(cherry picked from commit 6d0b74cde28ea0c1724f37ff799cd7524ff0d9b4)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix doubled message in verbose mode
The problem was doubled informative message in verbose mode (#6028)
`Bundler::Definition#missing_specs?` clears the `@resolve` ivar due to
the fact that `ensure` clause evaluates regardless whether exception
occurred. That results in repeated resolution, and, therefore, in
repeated debug messages.
This change moves ivars clearing into the `rescue` clause, so
`@resolve` will be cleared only in case when `BundlerError` occurs
I chose this fix because running deps resolution twice is a bad idea anyway and it needs to be prevented.
(cherry picked from commit 6c90bcb2969a302c33c8117b50c06543f3ba4741)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
remove non-ascii chars from binstubs man page
### What was the end-user problem that led to this PR?
There are some non-ascii characters in `man/bundle-binstubs.ronn` that is causing a build failure when `ronn` is compiling the man pages on linux
```
...
/usr/local/bin/ruby -S ronn --roff --pipe man/bundle-binstubs.ronn > man/bundle-binstubs.1
/usr/local/bundle/gems/ronn-0.7.3/lib/ronn/document.rb:192:in `split': invalid byte sequence in US-ASCII (ArgumentError)
from /usr/local/bundle/gems/ronn-0.7.3/lib/ronn/document.rb:192:in `sniff'
from /usr/local/bundle/gems/ronn-0.7.3/lib/ronn/document.rb:76:in `initialize'
from /usr/local/bundle/gems/ronn-0.7.3/bin/ronn:166:in `new'
from /usr/local/bundle/gems/ronn-0.7.3/bin/ronn:166:in `block in <top (required)>'
from /usr/local/bundle/gems/ronn-0.7.3/bin/ronn:166:in `map'
from /usr/local/bundle/gems/ronn-0.7.3/bin/ronn:166:in `<top (required)>'
from /usr/local/bundle/bin/ronn:23:in `load'
from /usr/local/bundle/bin/ronn:23:in `<main>'
rake aborted!
Command failed with status (1): [/usr/local/bin/ruby -S ronn --roff --pipe ...]
/opt/bundler/Rakefile:275:in `block (3 levels) in <top (required)>'
/opt/bundler/Rakefile:32:in `block in invoke'
/opt/bundler/Rakefile:31:in `invoke'
Tasks: TOP => man:build => man:build_all_pages => man/bundle-binstubs.1.txt => man/bundle-binstubs.1
(See full trace by running task with --trace)
/opt/bundler/spec/support/manpages.rb:11:in `setup': Failed building man pages (RuntimeError)
from /opt/bundler/spec/spec_helper.rb:47:in `<top (required)>'
from /usr/local/lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from /usr/local/lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from /usr/local/bundle/gems/rspec-core-3.6.0/lib/rspec/core/configuration.rb:1453:in `block in requires='
from /usr/local/bundle/gems/rspec-core-3.6.0/lib/rspec/core/configuration.rb:1453:in `each'
```
### What is your fix for the problem, implemented in this PR?
Replace characters with their ascii equivalent
(cherry picked from commit 69ca440c3a122b65e95dbcc203383ee835158e1c)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix "assigned but unused variable" warning in Ruby 2.5
We're seeing several "assigned but unused variable" warnings when we run `bundle` in Ruby 2.5 with `RUBYOPT=-w`.
This is because Ruby 2.5's unused variable check has been improved since https://github.com/ruby/ruby/commit/37b04894f20a5d3701309a2055bfa03b9d760090, and [previous double-assignment technique](https://github.com/bundler/bundler/blob/fea177f61df71121c6f9422a74b093e42c504388/lib/bundler/installer.rb#L116) no longer works as an anti-warning workaround.
For example, here's a short reproducible code that doesn't warn in 2.4 but warns in 2.5:
```ruby
`def a() x = x = 1; end`
```
So here are updated workarounds against this warning, which are valid for both Ruby < 2.5 and >= 2.5.
(cherry picked from commit 3847fd5e9605c794fd1f6362029c57c466d3d77a)
|
| |
|
|
|
|
|
|
|
|
| |
Load digest subclasses in a thread-safe manner
The problem was `digest` files would sometimes be loaded twice.
My diagnosis was we needed to load the `digest` files using the `::Digest` method, which is explicitly thread-safe.
(cherry picked from commit 8efc35c2e2f68eae40639390b9ced72156d5d4a4)
|
| |
|
|
|
|
|
|
| |
Avoid RubyGems psych warning breaking the tests
This, along with https://github.com/rubygems/rubygems/pull/2034, should get tests passing again 🙌
(cherry picked from commit ac7e1f7d10bd887cfe8e137d07f28e9fed1ee8fc)
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fix uninitialised constant Gem::ConfigFile::SYSTEM_CONFIG_PATH
### What was the end-user problem that led to this PR?
`bundle env` uses the constant `Gem::ConfigFile::SYSTEM_CONFIG_PATH` which is not defined in early versions of RubyGems.
See: https://travis-ci.org/bundler/bundler/builds/276981165
### What is your fix for the problem, implemented in this PR?
While `SYSTEM_CONFIG_PATH` is not defined for earlier versions of RubyGems, a constant called `Gem::ConfigFile::SYSTEM_WIDE_CONFIG_FILE` does appear to be both in current and early versions of RubyGems which contains the path (plus the ruby config file) we want.
### Why did you choose this fix out of the possible options?
This fix is compatible with all the tested versions of RubyGems in CI and is not overly complex.
|
| |/ |
|
| | |
|
