| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |\
| |
| |
| |
| |
| | |
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.
|
| | | | | |
| | | | |
| | | | |
| | | | | |
run on the current platform
|
| | | | | | |
|
| | | | | | |
|
| |/ / / / |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Only trap INT signal and set to DEFAULT
### What was the end-user problem that led to this PR?
The problem was commands like `nohup bundler exec {program}` wouldn't work as intended. For example, if a `HUP` signal were to be sent to the process running the `bundle exec ..`, it should in theory not terminate. Because, `nohup` would `IGNORE` that signal. But, that is not what the case is case is currently.
### What was your diagnosis of the problem?
My diagnosis was, if a process/bundler execution already had a `SIGNAL` set to it, example `HUP`, then performing `bundle exec {program}`, would mean that bundler resets any prior `SIGNAL`s on that process and sets them to `DEFAULT`.
### What is your fix for the problem, implemented in this PR?
My fix to the problem is to only trap `SIGNAL`s that we think should be set to `DEFAULT`, in this case, `INT`.
### Why did you choose this fix out of the possible options?
I chose this fix because its lot less aggressive than setting every signal to `DEFAULT`, and gives us the work with a smaller set of `SIGNAL`s. It also felt cleaner than having to trap a signal first and then restore to its predecessor value.
----
This is a dump that shows the before and after signals, when `nohup bundle exec {program }` gets run.
```
SIGEXIT: Before Handler: (), Current Handler: (DEFAULT)
SIGHUP: Before Handler: (IGNORE), Current Handler: (DEFAULT)
SIGINT: Before Handler: (#<Proc:0x00007f8e100534f8@/Users/<>/.rvm/gems/ruby-2.4.2/gems/bundler-1.16.0/exe/bundle:5>), Current Handler: (DEFAULT)
SIGQUIT: Before Handler: (DEFAULT), Current Handler: (DEFAULT)
SIGTRAP: Before Handler: (SYSTEM_DEFAULT), Current Handler: (DEFAULT)
SIGABRT: Before Handler: (SYSTEM_DEFAULT), Current Handler: (DEFAULT)
SIGIOT: Before Handler: (SYSTEM_DEFAULT), Current Handler: (DEFAULT)
SIGEMT: Before Handler: (SYSTEM_DEFAULT), Current Handler: (DEFAULT)
SIGSYS: Before Handler: (), Current Handler: (DEFAULT)
SIGPIPE: Before Handler: (), Current Handler: (DEFAULT)
SIGALRM: Before Handler: (DEFAULT), Current Handler: (DEFAULT)
SIGTERM: Before Handler: (DEFAULT), Current Handler: (DEFAULT)
SIGURG: Before Handler: (SYSTEM_DEFAULT), Current Handler: (DEFAULT)
SIGTSTP: Before Handler: (SYSTEM_DEFAULT), Current Handler: (DEFAULT)
SIGCONT: Before Handler: (SYSTEM_DEFAULT), Current Handler: (DEFAULT)
SIGCHLD: Before Handler: (SYSTEM_DEFAULT), Current Handler: (DEFAULT)
SIGCLD: Before Handler: (SYSTEM_DEFAULT), Current Handler: (DEFAULT)
SIGTTIN: Before Handler: (SYSTEM_DEFAULT), Current Handler: (DEFAULT)
SIGTTOU: Before Handler: (SYSTEM_DEFAULT), Current Handler: (DEFAULT)
SIGIO: Before Handler: (SYSTEM_DEFAULT), Current Handler: (DEFAULT)
SIGXCPU: Before Handler: (SYSTEM_DEFAULT), Current Handler: (DEFAULT)
SIGXFSZ: Before Handler: (SYSTEM_DEFAULT), Current Handler: (DEFAULT)
SIGPROF: Before Handler: (SYSTEM_DEFAULT), Current Handler: (DEFAULT)
SIGWINCH: Before Handler: (SYSTEM_DEFAULT), Current Handler: (DEFAULT)
SIGUSR1: Before Handler: (DEFAULT), Current Handler: (DEFAULT)
SIGUSR2: Before Handler: (DEFAULT), Current Handler: (DEFAULT)
SIGINFO: Before Handler: (SYSTEM_DEFAULT), Current Handler: (DEFAULT)
```
From this, we can see only `INT` is being trapped by bundler
```
SIGINT: Before Handler: (#<Proc:0x00007f8e100534f8@/Users/<>/.rvm/gems/ruby-2.4.2/gems/bundler-1.16.0/exe/bundle:5>), Current Handler: (DEFAULT)
```
hence, the only one being restored back to `DEFAULT`
----
Issue: https://github.com/bundler/bundler/issues/6150
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Before, we were trapping every non reserved signal
and setting it to DEFAULT. This meant, if there was
a prior signal set on a process, we were resetting it
with DEFAULT
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Fix hang when gemspec has incompatible encoding
### What was the end-user problem that led to this PR?
The problem was that if a gemspec had a non ascii character on it, and the external encoding is not utf-8, bundler would fail with a very cryptic error. CircleCI is very likely to reproduce this bug since its base images default to `LANG=C`. See [here](https://circleci.com/gh/deivid-rodriguez/pry-byebug/12) for an example.
In bundler's master, `bundle install` seems to hang in this same situation. I have no idea why but CPU usage goes crazy (100%) when running something like `LANG=C bundle install` with such a gemspec.
Note that adding a utf-8 magic encoding comment seems to fix the problem, but I think `bundler` should just work in this situation, or at least give the user a more helpful error message. And of course never hang either.
### What was your diagnosis of the problem?
My diagnosis was that bundler was reading an incompatible character from the gemspec and was not able to deal with it, nor give a useful error message.
### What is your fix for the problem, implemented in this PR?
My fix initial fix was to at least give a better error message, preventing the method building the error message itself from blowing up due to incompatible encodings. This is the initial patch that I wrote to improve the error message:
```diff
diff --git a/lib/bundler/dsl.rb b/lib/bundler/dsl.rb
index 37bfe3674..79ef563d1 100644
--- a/lib/bundler/dsl.rb
+++ b/lib/bundler/dsl.rb
@@ -581,7 +581,14 @@ The :#{name} git source is deprecated, and will be removed in Bundler 2.0.
def parse_line_number_from_description
description = self.description
- if dsl_path && description =~ /((#{Regexp.quote File.expand_path(dsl_path)}|#{Regexp.quote dsl_path.to_s}):\d+)/
+ return [nil, description] unless dsl_path
+
+ quoted_expanded_dsl_path = Regexp.quote(File.expand_path(dsl_path))
+ quoted_dsl_path = Regexp.quote(dsl_path.to_s)
+
+ return [nil, description] unless Encoding.compatible?(quoted_dsl_path, description) && Encoding.compatible?(quoted_expanded_dsl_path, description)
+
+ if description =~ /((#{quoted_expanded_dsl_path}|#{quoted_dsl_path}):\d+)/
trace_line = Regexp.last_match[1]
description = description.sub(/#{Regexp.quote trace_line}:\s*/, "").sub("\n", " - ")
end
```
With that patch, the error would be more clear, pointing at the exact line in the gemspec where the incompatible character was found.
However, after that I considered that maybe bundler doesn't need to read the gemspec as a text file, but could read it "binarily". That seemed to fix the problem indeed and made the `bundle install` succeed in this situation.
### Why did you choose this fix out of the possible options?
I chose this fix because not only fixes the error message but also seems to make `bundler` just work.
|
| | | | | | | |
|
| | | |/ / /
| |/| | |
| | | | |
| | | | | |
Not sure about the reason, but binary read fixes it...
|
