| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |/ / / /
| | | |
| | | |
| | | |
| | | |
| | | | |
This is extremely inconvenient (or sometimes plain broken) when the
person running the tests has `commit.gpgsign` enabled in their global
Git configuration.
|
| |\ \ \ \
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
r=colby-swandale
Fix `bundle gem` generating unparsable ruby
### What was the end-user problem that led to this PR?
The problem was that the main file in a gem generated by `bundle gem` can't be inspected via `rubocop`.
### What was your diagnosis of the problem?
My diagnosis was `bundler` was generating unparsable ruby in the generated gem.
### What is your fix for the problem, implemented in this PR?
My fix was to change the offending template to generate valid ruby code.
### Why did you choose this fix out of the possible options?
I chose this fix because it's the only one, really.
|
| |/ / /
| | |
| | |
| | | |
Introduced in https://github.com/bundler/bundler/pull/6267.
|
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | | |
Remove comment with timestamp on `bundle add`
As discussed on #6193 this PR simply removes the comment timestamp when adding a gem via command line.
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Update docs to reflect revised guidance to check in locks for gems
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...
- Bundler stopped gitignoring gem locks. The change was merged in but we need to reflect that change in documentation.
### What was your diagnosis of the problem?
My diagnosis was...
- To add in documentation explaining why Bunder now does _not_ gitignore gem locks.
### What is your fix for the problem, implemented in this PR?
My fix...
- Update the `gemfile.lock` section of `bundle install` man pages as well as the `gemfile` man page.
### Why did you choose this fix out of the possible options?
I chose this fix because...
- This addresses open issue https://github.com/bundler/bundler/issues/5879
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
After reviewing, I think the question and answer is a bad fit for the
`gemfile` man page. It does seem like a good fit for the FAQ page on the
Bundler documentation site, though, and I'll add it over there.
|
| | | | | |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Add enforcement steps and examples to the CoC.
package.community has done a terrific job with their clear explanation
of what enforcing a CoC looks like. Bundler is a better place when
everyone knows what kind of behavior is expected, and what will happen
if those expectations are not met, for whatever reason.
|
| | | | | | |
|
| | | | | | |
|
| | | |_|/
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | | |
package.community has done a terrific job with their clear explanation
of what enforcing a CoC looks like. Bundler is a better place when
everyone knows what kind of behavior is expected, and what will happen
if those expectations are not met, for whatever reason.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
r=indirect
Gracefully handle when the lockfile is missing spec entries for the current platform
### What was the end-user problem that led to this PR?
The problem was users could get `Unable to find a spec satisfying ... perhaps the lockfile is corrupted?` error messages, particularly when they use multiple platforms.
Fixes #6079.
### What was your diagnosis of the problem?
My diagnosis was the lockfile _was_ indeed corrupted, because it was missing `spec_name (version)` entries, but resolution could still be skipped (preventing those gems from being added back in).
### What is your fix for the problem, implemented in this PR?
My fix checks whether all specs are present _in the lockfile_ (e.g. not locally) for the current platform, and considers that a "change" that forces the resolver to run, allowing those missing specs to be added back to the bundle.
### Why did you choose this fix out of the possible options?
I chose this fix because it was a way to force re-resolution in a way that ties into our existing `#change_reason` infrastructure. Additionally, it shouldn't have much of a performance overhead, since the calculation is only made when we're converging locked specs anyways.
|
