| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fix failure when exception backtrace is nil
Resolves #6342
### What was the end-user problem that led to this PR?
Instead of throwing a readable error, Bundler failed and generated an issue report template (see details in #6342).
### What was your diagnosis of the problem?
My diagnosis was that nil safety is hard in Ruby.
### What is your fix for the problem, implemented in this PR?
To check whether backtrace is nil before sending it a `take_while` method.
### Why did you choose this fix out of the possible options?
I chose this fix because I see no other solutions.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
r=colby-swandale
[CompactIndexClient::Updater] Use filesystem_access when copying files
### What was the end-user problem that led to this PR?
The problem was users could see the error template when they do not have write permissions to their temporary directory.
Closes https://github.com/bundler/bundler/issues/6289
### What was your diagnosis of the problem?
My diagnosis was we need to use `SharedHelpers.filesystem_access` when writing files.
### What is your fix for the problem, implemented in this PR?
My fix wraps usage of `cp`
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Update brew install for groff
[dupes](https://github.com/Homebrew/homebrew-dupes) tap is deprecated, `groff` is now in [hombrew-core](https://github.com/Homebrew/homebrew-core/blob/master/Formula/groff.rb).
Also fixed a missing single quote while I was at it :)
|
| |/ / / |
|
| |\ \ \
| |_|/
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
bundler:segiddins/fail-gracefully-when-resetting-to-rev-fails, r=colby-swandale
[GitProxy] Fail gracefully when resetting to the given revision fails
### What was the end-user problem that led to this PR?
See https://github.com/bundler/bundler/issues/6324 for context.
The problem was when a git gem referenced a branch, and you tried to install on a machine without the revision in the lockfile cached, Bundler would print the following error:
```
Git error: command `git reset --hard cb70aded58b9215a495f0509e49daef930eec478` in directory
/home/deivid/.rbenv/versions/2.5.0/lib/ruby/gems/2.5.0/bundler/gems/decidim-cb70aded58b9 has failed.
If this error persists you could try removing the cache directory
'/home/deivid/.rbenv/versions/2.5.0/lib/ruby/gems/2.5.0/cache/bundler/git/decidim-9495d3039168996748af12c0fdb04debdea10392'
```
The problem was that removing the cache directory doesn't help.
### What was your diagnosis of the problem?
My diagnosis was we needed to print a `RevisionNotFound` error when that `git reset --hard` failed.
### What is your fix for the problem, implemented in this PR?
My fix rescues git command failures resulting from that `git reset --hard` and re-raises a more appropriate error message:
```
Revision cb70aded58b9215a495f0509e49daef930eec478 does not exist in the repository https://github.com/decidim/decidim. Maybe you misspelled it?
```
### Why did you choose this fix out of the possible options?
I chose this fix because it didn't involve bubbling information up from the git proxy to the definition. Ideally we'd re-rescue this error somewhere and suggest a `bundle update --source`, but that can be done in a separate PR.
|
| | |/ |
|
| |\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
r=segiddins
Use Bundler.rubygems.inflate instead of the Gem::Util method directly
### What was the end-user problem that led to this PR?
The problem was Bundler was using RubyGems methods directly that may change their interface over time.
### What was your diagnosis of the problem?
My diagnosis was we should use `Bundler.rubygems` to encapsulate those method calls.
|
| |/ |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fix link to contributing doc
### What was the end-user problem that led to this PR?
Broken link to contributing doc in bot response
### What is your fix for the problem, implemented in this PR?
Corrected the link
Fixes #6332
|
| | | |
|
| |\ \
| |/
|/|
| |
| |
| | |
Add a POLICIES document
This isn't intended to be authoritative, but it's a start!
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| | |
The links to bundler.io were leading to a 404 error in GitHub because the full URL hadn't been written out.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Raise an error when attempting to set an expectation on nil
Thanks so much for the contribution!
To make reviewing this PR a bit easier, please fill out answers to the following questions.
### What was the end-user problem that led to this PR?
The problem was we could accidentally set an expectation on `nil`, leading to an RSpec warning
### What was your diagnosis of the problem?
My diagnosis was we should just error when we do so
|
| | | | |
|
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Add a spec for bundle lock not downloading gems
### What was the end-user problem that led to this PR?
The problem was we were unsure (in https://github.com/bundler/bundler/issues/6312) whether lock had this behavior.
### What was your diagnosis of the problem?
My diagnosis was it did, and I came to that conclusion via this test!
|
| |/ / |
|
| |\ \
| | |
| | |
| | |
| | |
| | | |
Fix source_location call in PR 6237 and commit fbb1ff7
Thanks to @nobu for pointing out the error (which was mine). `source_location` returns an array, not a string.
|
| | | |
| | |
| | |
| | | |
Thanks to @nobu for pointing out the error.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
r=indirect
Deprecate safe_level of `ERB.new` in Ruby 2.6
### What was the end-user problem that led to this PR?
The interface of `ERB.new` will change from Ruby 2.6.
> 2nd, 3rd and 4th arguments of ERB.new are deprecated. 2nd
> argument (safe_level) will be dropped in the future and
> some of those arguments (trim_mode, eoutvar) are changed to
> keyword arguments. [Feature #14256]
https://github.com/ruby/ruby/blob/v2_6_0_preview1/NEWS#stdlib-updates-outstanding-ones-only
The following addresses are related commits.
- ruby/ruby@cc777d0
- ruby/ruby@8b9a3ea
This change will cause the users to see a warning as described below.
### What was your diagnosis of the problem?
In Ruby 2.6, a warning is displayed when using the interface of Ruby 2.5 or lower.
This warning can also be confirmed in Travis CI.
```console
/home/travis/.rvm/gems/ruby-head/gems/rspec-core-3.7.1/lib/rspec/core/configuration_options.rb:171:
warning: Passing safe_level with the 2nd argument of ERB.new is
deprecated. Do not use it, and specify other arguments as keyword
arguments.
/home/travis/.rvm/gems/ruby-head/gems/rspec-core-3.7.1/lib/rspec/core/configuration_options.rb:171:
warning: Passing trim_mode with the 3rd argument of ERB.new is
deprecated. Use keyword argument like ERB.new(str, trim_mode: ...)
instead.
```
https://travis-ci.org/bundler/bundler/jobs/348560176#L1137-L1138
### What is your fix for the problem, implemented in this PR?
This PR suppresses the above deprecation warnings of ruby-head (Ruby 2.6) .
### Why did you choose this fix out of the possible options?
Switch `ERB.new` interface using `RUBY_VERSION`. Because Bundler supports multiple Ruby versions, it need to use the appropriate interface.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
### What was the end-user problem that led to this PR?
The interface of `ERB.new` will change from Ruby 2.6.
> 2nd, 3rd and 4th arguments of ERB.new are deprecated. 2nd
> argument (safe_level) will be dropped in the future and
> some of those arguments (trim_mode, eoutvar) are changed to
> keyword arguments. [Feature #14256]
https://github.com/ruby/ruby/blob/v2_6_0_preview1/NEWS#stdlib-updates-outstanding-ones-only
The following addresses are related commits.
- ruby/ruby@cc777d0
- ruby/ruby@8b9a3ea
This change will cause the users to see a warning as described below.
### What was your diagnosis of the problem?
In Ruby 2.6, a warning is displayed when using the interface of
Ruby 2.5 or lower.
This warning can also be confirmed in Travis CI.
```console
/home/travis/.rvm/gems/ruby-head/gems/rspec-core-3.7.1/lib/rspec/core/configuration_options.rb:171:
warning: Passing safe_level with the 2nd argument of ERB.new is
deprecated. Do not use it, and specify other arguments as keyword
arguments.
/home/travis/.rvm/gems/ruby-head/gems/rspec-core-3.7.1/lib/rspec/core/configuration_options.rb:171:
warning: Passing trim_mode with the 3rd argument of ERB.new is
deprecated. Use keyword argument like ERB.new(str, trim_mode: ...)
instead.
```
https://travis-ci.org/bundler/bundler/jobs/348560176#L1137-L1138
### What is your fix for the problem, implemented in this PR?
This PR suppresses the above deprecation warnings of ruby-head (Ruby 2.6) .
### Why did you choose this fix out of the possible options?
Switch `ERB.new` interface using `RUBY_VERSION`. Because Bundler
supports multiple Ruby versions, it need to use the appropriate interface.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Improve yanked gem error message
The problem was that the error message for a yanked Gem told the user to:
> update your bundle to a different version of foo (1.0)
This is slightly misleading because in this example, foo 1.0 is the version that has been yanked. They should use any verion of foo **other** than 1.0.
My diagnosis was that the error message interpolated the gem specification (which converts to a string as "NAME (VERSION)") rather than just the name of the gem in this instance.
My fix was to change that occurrence of the gem specification to just the gem name.
I chose this fix because it was the only way that occurred to me to do it.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
It makes more sense to say
> update your bundle to a different version of foo
than
> update your bundle to a different version of foo (1.0)
|
| |\ \ \ \ \
| |_|_|/ /
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Document `# frozen_string_literal` in `bundle init` Gemfile
Thanks so much for the contribution!
To make reviewing this PR a bit easier, please fill out answers to the following questions.
### What was the end-user problem that led to this PR?
An enhancement request to bundle-init docu as per - issue 6140
### What was your diagnosis of the problem?
n/a
### What is your fix for the problem, implemented in this PR?
Updated the man/bundle-init.ronn file to include brief description of frozen string literal, and added a SEE ALSO section with link to Gemfile(5) webpage
### Why did you choose this fix out of the possible options?
File edited to try and reflect the previous discussion regarding what was required.
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Link out directly to contributor guidelines
Hey team,
The "Contributing" section confusingly sends contributors over to the "Documentation" README, and from there, contributors have to click on "Overview" to actually get to the guidelines. Since it's easier to cut out those two steps, I've rephrased a sentence and provide the direct link to the contributor guidelines here.
Thanks so much for the contribution!
To make reviewing this PR a bit easier, please fill out answers to the following questions.
### What was the end-user problem that led to this PR?
The problem was...
...that it wasn't clear why contributors had to complete two steps to get to the contributor guidelines. And because it isn't clear once they get to "Documentation" which link is the actual guideline, it's much simpler to link out to it directly from the Bundler README.
### What was your diagnosis of the problem?
My diagnosis was...
....to cut out the middle man, so to speak.
### What is your fix for the problem, implemented in this PR?
My fix...
1. rephrase a sentence
2. link out directly to the contributor guidelines README
### Why did you choose this fix out of the possible options?
I chose this fix because...
...it's easy to implement and makes the most sense from the user's POV.
|
| |/ / / / /
| | | | |
| | | | |
| | | | |
| | | | | |
Hey team,
The "Contributing" section confusingly sends contributors over to the "Documentation" README, and from there, contributors have to click on "Overview" to actually get to the guidelines. Since it's easier to cut out those two steps, I've rephrased a sentence and provide the direct link to the contributor guidelines here.
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Update Bundler Contributor Guidelines README
Thanks so much for the contribution!
To make reviewing this PR a bit easier, please fill out answers to the following questions.
### What was the end-user problem that led to this PR?
The problem was...
...the contributor guide was is too long and too confusing. It was difficult to determine what information needed to be reviewed in what sequence. We wanted to make the guidelines easy to read and easy to follow.
### What was your diagnosis of the problem?
My diagnosis was...
...to condense the information
### What is your fix for the problem, implemented in this PR?
My fix...
to condense the information presented and truncate the number of sections. See changes:
### Why did you choose this fix out of the possible options?
I chose this fix because...
...it's a quick win!
|
| | | | | | |
| | | | | |
| | | | | | |
Per @hmistry's suggestions, I've moved the development instructions outside of the bulleted list and made it its own sentence. And I've shortened the copy under the "Contributing to Bundler" header.
|
| | | |_|/ /
| |/| | |
| | | | |
| | | | |
| | | | | |
Hey team,
As part of an ongoing effort to revamp the docs, I've been working with @indirect to rewrite the contributor guidelines README. We wanted to streamline the way the information was laid out, and make it more explicit to potential contributors how they can contribute and what next steps they needed to take. We condensed everything down to three sections (a general guidelines section, contributor section, and a new, supporting Bundler section). Everything links out to existing documentation.
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Add config variable and check for platform warnings
Thanks so much for the contribution!
To make reviewing this PR a bit easier, please fill out answers to the following questions.
### What was the end-user problem that led to this PR?
The user needed a way to turn off platform warnings.
### What was your diagnosis of the problem?
Creating a config variable to solve the above problem.
### What is your fix for the problem, implemented in this PR?
Added a key `disable_platform_warnings` in settings and placed check at the relevant place to disable warnings.
### Why did you choose this fix out of the possible options?
We will by default show warnings but the user might want to disable them, so using a config variable looked a good option.
Fixes #6124
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| |\ \ \ \ \ \
| |_|/ / / /
|/| | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Use Gem::Util.inflate instead of Gem.inflate
### What was the end-user problem that led to this PR?
When I released RubyGems 3.0, users can not use bundler with it.
### What was your diagnosis of the problem?
bundler still uses deprecated methods with https://github.com/rubygems/rubygems/pull/2214
### What is your fix for the problem, implemented in this PR?
Replace `Gem.inflate` to `Gem::Util.inflate`
|
| |/ / / / / |
|
| |\ \ \ \ \
| |_|_|/ /
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Don't GPG-sign test setup commits
Running `bin/rake spec` in the Bundler repository causes a bunch of failures if `commit.gpgsign` is set in the global Git configuration.
Bundler's tests were making Git commits and trying to GPG sign them.
Set `commit.gpgsign` to `false` when initializing a Git repository in the tests.
I chose this fix because the alternative would be to pass `--no-gpg-sign` every time a commit is made in the tests, which would have a bigger maintenance impact.
|
