delta/bundler.git, branch remove_global_path_appends_ruby_scope

Remove now unnecessary append_ruby_scope field

2019-05-07T13:39:17+00:00

Remove global_path_appends_ruby_scope setting

2019-05-07T13:35:46+00:00

This is a bug fix, so it makes no sense to make it configurable. Also,
the fix is unlikely to cause problems other than maybe needing a fresh
`bundle install` on some edge cases. So, let's ship the fix and remove
the setting.

Merge #7157

2019-05-06T16:04:24+00:00

7157: Improve azure configuration r=deivid-rodriguez a=deivid-rodriguez

### What was the end-user problem that led to this PR?

The problem was that failures in Azure are not logged, so it hard to improve the situation.

### What is your fix for the problem, implemented in this PR?

My fix is to configure Azure to run until completion without any timeouts, and remove intercepting the global timeout (which we did to make sure build is still green when it times out), because it's no longer necessary. Now we should be able to see the failures on every PR.

Co-authored-by: David Rodríguez

Set unlimited running time in Azure

2019-05-05T20:30:29+00:00

Merge #7160

2019-05-05T18:54:35+00:00

7160: Bump Rubocop version r=deivid-rodriguez a=natesholland

### What was the end-user problem that led to this PR?

There was not a problem, just some housekeeping.

### What was your diagnosis of the problem?

I wanted to see if bumping the latest Rubocop version would bring in any new fixes or updates. It did not but I figured it didn't hurt to bump the version in case new PRs are affected by the new cops.

### What is your fix for the problem, implemented in this PR?

I bumped the patch version of RubCop by 1.

### Why did you choose this fix out of the possible options?

I chose this fix because it was the only logical thing to do.

Co-authored-by: Nate Holland

Bump Rubocop version

2019-05-05T16:56:52+00:00

I was hoping this would turn up new cops or changes. It did not end up
changing anything.

Merge #7142

2019-05-05T08:53:23+00:00

7142: Fully switch to https sources r=indirect a=deivid-rodriguez

### What was the end-user problem that led to this PR?

The problem was that in https://github.com/bundler/bundler/pull/7000 I implemented a plan to migrate to https source by default and deprecate github/gist/bitbucket builtin sources, but I changed my mind and I think it's overkill.

The reasons I changed my mind are:

* We [actually announced the switch](https://bundler.io/blog/2019/01/03/announcing-bundler-2.html) and the fact that it didn't happen was not intented. So this can be considered as fixing a bug.

* We have warned non https git sources for ages

https://github.com/bundler/bundler/blob/a6533c0fe6541cc929f895ee0b7a9b673d34cb4d/lib/bundler/source_list.rb#L144-L153

I think people should be ready by now.

Also, we introduced a new setting `github.https` that seems to do essentially the same thing as `git.allow_insecure`. 

### What is your fix for the problem, implemented in this PR?

My fix is to take the initial approach of https://github.com/bundler/bundler/pull/6911 and actually do this in the next release.

Co-authored-by: David Rodríguez

Merge #7149

2019-05-03T08:48:33+00:00

7149: Fix bundle update crash r=deivid-rodriguez a=deivid-rodriguez

### What was the end-user problem that led to this PR?

The problem was that I introduced a regression with https://github.com/bundler/bundler/pull/6329. When running `bundle update `, where `` is included in the Gemfile, but it's for another platform from the current one, `bundle` would crash with the following error:

```
NoMethodError: undefined method `source' for nil:NilClass
  /home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/lib/bundler/cli/update.rb:86:in `block in run'
  /home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/lib/bundler/cli/update.rb:78:in `each'
  /home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/lib/bundler/cli/update.rb:78:in `run'
  /home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/lib/bundler/cli.rb:280:in `block in update'
  /home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/lib/bundler/settings.rb:129:in `temporary'
  /home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/lib/bundler/cli.rb:279:in `update'
  /home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
  /home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/lib/bundler/vendor/thor/lib/thor/invocation.rb:126:in `invoke_command'
  /home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/lib/bundler/vendor/thor/lib/thor.rb:387:in `dispatch'
  /home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/lib/bundler/cli.rb:26:in `dispatch'
  /home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/lib/bundler/vendor/thor/lib/thor/base.rb:466:in `start'
  /home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/lib/bundler/cli.rb:17:in `start'
  /home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/exe/bundle:21:in `block in '
  /home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/lib/bundler/friendly_errors.rb:123:in `with_friendly_errors'
  /home/deivid/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.0.pre.1/exe/bundle:13:in `'
  /home/deivid/.rbenv/versions/2.6.3/bin/bundle:23:in `load'
  /home/deivid/.rbenv/versions/2.6.3/bin/bundle:23:in `'
```


### What was your diagnosis of the problem?

My diagnosis was that we can't always rely on the spec being updated not being `nil` in the definition. It can be `nil` for gems in excluded groups, or for gems included only for platforms different from the current one.

### What is your fix for the problem, implemented in this PR?

My fix is to handle this case and show a proper error.

### Why did you choose this fix out of the possible options?

I chose this fix because it's user friendly.


Co-authored-by: David Rodríguez

Merge #7153

2019-05-02T14:37:43+00:00

7153: Rename local variables for readability r=deivid-rodriguez a=mtsmfm

Extracted from https://github.com/bundler/bundler/pull/7143#discussion_r279187838

> Also, I would split the variable rename, which is great because it makes the code more readable, to a separate commit

### What was the end-user problem that led to this PR?

No end-user is affected because it's just local var name.

As a bundler contributor, I think it's much easier to understand if we rename them.
When I was investigating https://github.com/bundler/bundler/pull/7143, it's hard to understand what `other` stuff and `deps2` is.

Co-authored-by: Fumiaki MATSUSHIMA

Merge #7147

2019-05-02T14:03:46+00:00

7147: Fix specs with rubygems master installed globally r=deivid-rodriguez a=deivid-rodriguez

### What was the end-user problem that led to this PR?

The problem was if you have rubygems's master installed globally, bundler specs no longer pass.

### What was your diagnosis of the problem?

My diagnosis was that having rubygems master installed, installs bundler's master as a default gem. That actually makes bundler behave better. In particular, `bundle show` and `bundle licenses` start properly handling the `bundler` gem itself.

### What is your fix for the problem, implemented in this PR?

My fix is to change bundler's code to fix this specs in every situation, and not only when the bundler version being tested is also installed as a default gem.

NOTE: I also included some changes to unify `bundle show` deprecation specs in the file that tests all deprecations.

Co-authored-by: David Rodríguez