Resolver had internal logic to prioritize locked versions when sorting
versions, however part of it was not being actually hit because of how
unlocking worked in the resolver: a package was allow to be unlocked
when that was explicit requested or when the list of unlocks was empty.
That did not make a lot of sense and other cases were working because
the explicit list of unlocks was getting "artificially filled".
Now we consider a package unlocked when explicitly requested (`bundle
update <package>`), or when everything is being unlocked (`bundle
install` with no lockfile or `bundle update`).
This makes things simpler and gets the edge case added as a test case
working as expected.
https://github.com/rubygems/rubygems/commit/b8e55087f0
Bundler does not really have a concept of "development dependencies",
like RubyGems has. Bundler has the more generic concept of "groups".
Under the hood, the `gemspec` DSL will put gemspec development
dependencies under a `:development` Gemfile group, but there's no reason
to instantiate these as development dependencies, they are regular
runtime dependencies, except that they belong in a group named
:development.
By never instantiating development dependencies at all, we avoid having
to introduce hacks to "undo" the type Bundler does not know about, and I
also think the error messages read better.
https://github.com/rubygems/rubygems/commit/9a06fa5bda
When Bundler refuses to install in frozen mode, sometimes it would
incorrectly claim that some dependencies have been added to the Gemfile
when that's not really the case. Fix that by making sure
`locked_dependencies` always has all locked dependencies, even when
unlocking,
Additionally, the suggestion to run `bundle install` is also confusing
when unlocking, since `bundle update` is what has been run. So skip that
part as well when unlocking.
https://github.com/rubygems/rubygems/commit/64d84ad7d8
Platforms specific gems not compatible with the current Ruby should not
make `bundle cache` fail and should not get removed from the cache since
they still may be useful in other rubies.
https://github.com/rubygems/rubygems/commit/717b43f565
Currently evenn if the require actually fails, they suggest that the
file was actually loaded, which is confusing. I reworded them to reduce
this confusion.
When a positive integer limit is given, `rand` method of a RNG object
is expected to return a value between 0 and the limit (exclusive).
Fix shuffle_spec.rb like as the similar code in sample_spec.rb, and
add tests for greater values.
TODO:
- Return a value that is equal to or greater than the limit given to
the RNG object.
- Extract common code about RNG objects to a shared file.
- Similar change than https://github.com/rubygems/rubygems/commit/29a1be0008e6,
keep a single source of truth where we store the platform.
The only change worth highlighing is the platform "maglev".
It was not part of the supported platform of dependencies,
so calling `gem 'foo', plaftorm: 'maglev'` would not work.
However, it was supposed to according to https://github.com/rubygems/rubygems/commit/45ec86e2e528.
That's why it was possible to do `Bundler.current_ruby.maglev?` or
`Bundler.current_ruby.maglev_30?`.
I didn't change the current behaviour and maglev is not supported,
though I kept the `*maglev` methods as I believe CurrentRuby is
public API.
https://github.com/rubygems/rubygems/commit/29e219ebcf
But we stub-out GEM_HOME variable for test-bundled-gems and others on ruby/ruby. It means
the installation path mismatched with GEM_HOME variable always. We can't test this example
collectly.
```
1)
Gem.bin_path finds executables of default gems, which are the only files shipped for default gems FAILED
Expected File.exist? "/Users/hsbt/Documents/github.com/ruby/ruby/.bundle/gems/bundler-2.7.0.dev/exe/bundle"
to be truthy but was false
```
