| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
| |
See https://github.com/ruby/ruby/commit/0af050993e9cc55e2f58d8f4677c1521bacf5bea
|
| | |
|
| |\
| |
| |
| |
| |
| | |
Fix codeclimate badge
Old badge shows status unknown, so replace it with new maintainability badge
|
| | |
| |
| | |
Old badge shows status unknown, so replace it with new maintainability badge
|
| |\ \
| |/
|/|
| |
| |
| | |
Re-order gem dependency for Ruby 1.8 build matrix.
Fixes https://travis-ci.org/bundler/bundler/jobs/320785817
|
| |/ |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | | |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Show warning message about binstub outside generation.
/cc @indirect
Fixes #6149.
Originated from https://github.com/bundler/bundler/issues/6149#issuecomment-347783823
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
Fixes #6149.
|
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| |/ / |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| |\ \ \
| |_|/
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Ensure git is executed inside the gemspec dir
### What was the end-user problem that led to this PR?
Executables from bundled gems weren't available.
```
Gem::Exception: can't find executable <EXEC-FILENAME> for gem <GEM-NAME>
/Users/elia/.rvm/rubies/ruby-2.3.4/lib/ruby/site_ruby/2.3.0/bundler/rubygems_integration.rb:458:in `block in replace_bin_path'
/Users/elia/.rvm/rubies/ruby-2.3.4/lib/ruby/site_ruby/2.3.0/bundler/rubygems_integration.rb:478:in `block in replace_bin_path'
…
```
### What was your diagnosis of the problem?
When a Gemfile was pointing to a local gem using git to list its files the git command
was executed from within the wrong dir.
### What is your fix for the problem, implemented in this PR?
Initially I added `-C #{__dir__}` to the `git ls-files -z` command.
### Why did you choose this fix out of the possible options?
Realized `-C` wasn't safe and opted for stuff already available in the corelib, i.e. `Dir.chrid` instead of, say, escaping with `shellwords`.
---
I know the line is long-ish, happy to fix it in the way you want
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
When a Gemfile was pointing to a local gem using git to list its files the git command
was executed from within the wrong dir. This fixes the issue without:
1. introducing new dependencies (e.g. `shellwords`)
2. any risks with non-trivial paths (e.g. paths containing spaces)
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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?
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
this test appears to only fail when the server is rubygems.org, so I
moved the test into realworld and pulled in vcr.
|
| | | | | |
|
| | |/ /
| | |
| | |
| | |
| | |
| | | |
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.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| |/ /
| |
| |
| | |
f06405 caused a regression with warbler, described in #6165
|
| |\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |/ |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Stop requesting changelogs in PRs
We added this requirement before the changelog was automated. Now that the changelog generated by a script, it's not helpful for PRs to update the changelog anymore, so we shouldn't expect it anymore.
### What was the end-user problem that led to this PR?
We had to [ask a PR to remove a changelog entry](https://github.com/bundler/bundler/pull/6157#discussion_r149701953), even though the PR was following [the docs](https://github.com/bundler/bundler/blob/374caf6ede2cf4de7d2196aa2e2adef782bea5bd/doc/development/PULL_REQUESTS.md#changelogmd).
### What was your diagnosis of the problem?
It looks like we failed to update the docs when we automated generating the changelog.
### What is your fix for the problem, implemented in this PR?
Removing the changelog requirement from the docs hopefully means that future PRs will not include changelog entries, and we can generate future changelogs automatically.
### Why did you choose this fix out of the possible options?
I chose this fix because it seemed like the smallest change that would accomplish the goal.
/cc @mattbrictson
|
| | |
| |
| | |
We added this requirement before the changelog was automated. Now that the changelog generated by a script, it's not helpful for PRs to update the changelog anymore, so we shouldn't expect it anymore.
|
| |\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
This commit 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.
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Update `config` page link to the recent version
### What was the end-user problem that led to this PR?
In the `man/bundle-gem.ronn`, we are using a hard-coded version number to link the `bundle-config` doc, which is `v1.14` in this case. Ref: https://bundler.io/v1.16/man/bundle-gem.1.html
### What is your fix for the problem, implemented in this PR?
<del>This commit updates the link and uses a relative path so it will always point to the recent version.</del>
Edit: This commit updates the link to the current stable version.
|
| |/
|
|
|
|
|
|
| |
In the `man/bundle-gem.ronn`, we are using a reference from the
old version, which is `v1.14` in this case. This commit updates
that link to the current stable version.
Ref: https://bundler.io/v1.16/man/bundle-gem.1.html
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is a simple fix for #6114, in which sometimes conflict sets get so huge that
the current reducing code (which is based on Array#combination) breaks down.
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").
|
| |\ \
| |/
|/|
| |
| |
| | |
[Travis] Test against RubyGems 2.7.0
Since I just released 2.7.0, we now have to test against it!
|
| |/ |
|
| |\
| |
| |
| | |
Version 1.16.0
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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)
|
