Merge #7580

7580: Automultiplatform again r=indirect a=deivid-rodriguez

This PR is a reintroduction of #7215, now that I consider the multiplatform feature usable enough.

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

The problem was that currently if the gemfile include gems for specific platforms, like the default `gem 'tzinfo-data', platforms: [:mingw, :mswin, :x64_mingw, :jruby]` Rails uses, bundler will always print a noisy warning, but I don't think users are doing anything wrong, just running `bundle install` on it.

Also, unless they run `bundle lock --add-platform x86-mingw32 x86-mswin32 x64-mingw32 java`, and commit the resulting lockfile, they will continue to get the same warning over and over again.

### What was your diagnosis of the problem?

My diagnosis is that the fact that some gems will be unused under some platforms is inherent to the multiplatform feature itself, so we shouldn't warn about it because it's expected.

Take the following Gemfile for example (a simplification of the default Gemfile Rails generators create):

```ruby
source "https://rubygems.org"

gem "rails"

gem "tzinfo-data", platforms: "jruby"
```

If I type that Gemfile, it means that I'm explicitly opting into the multiplatform feature. So the behavior I would want as a user when I run `bundle install` on it is:

* Resolve and lock the Gemfile for all platforms (`jruby` and whatever platform I'm running).
* Install the resolution for the platform that I'm currently running.

That way, when the other developers of my team using `jruby` install the `Gemfile`, they install a predictable, deterministic resolution.

Currently, the only way to get that behavior is to run:

```
$ bundle install
$ bundle lock --add-platform java
```

But there's no way to do it without getting a warning on the first `bundle install`, which annoys people because it makes you think you're doing something wrong.

If you only plan to use MRI, you shouldn't specify any jruby-specific gems in your Gemfile and write instead:

```ruby
source "https://rubygems.org"

gem "rails"
```

If on the other hand you only plan to use jruby, then you should not specify any `platform` option at all and write

```ruby
source "https://rubygems.org"

gem "rails"

gem "tzinfo-data"
```

So, to sum up, I think the range of platforms users expect to support can be guessed implicit from the Gemfile and the running platform. So we should resolve by default for all those platforms and don't warn about behavior that's most likely expected.

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

My fix is to do the right thing by default, and not warn users at all. That is:

* Resolve the gemfile and lock it for all platforms present in the Gemfile.
* Install gems for the current platform if requested.

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

I chose this fix because I think it's better for our users. We currently have a specific setting to avoid this warning, which I guess we added given the complaints. We no longer need that setting, nor the warning, so I removed both.

Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>

0 files changed, 0 insertions, 0 deletions