When computing the solution set, if a gem is already loaded, make sure
to use the specification of the loaded one instead of the first
available as otherwise there is a risk that when multiple matches are
available the specification for the wrong version may be picked.
When this happens an error message will be triggered that looks like
can't activate json-2.3.0, already activated json-2.5.1
This can occur for distribution packaged vagrants as well as installs
for development purposes where the ruby install may contain a default
gem spec of an older version than is needed.
Fixes: #12521Fixes: vagrant-libvirt/vagrant-libvirt#1390
Maintain the solution file persisting dependency information on
disk but update the runtime representation to
Gem::Resolver::DependencyRequest instances which are expected
by the sets when locating matches.
Properly abide by prerelease setting in customized sets and
force prerelease matching when in the builtin set. If a request
is matched on a prerelease, and the request itself is not set
to allow prereleases, update it to ensure successful resolution.
When initializing for internal plugin resolution inspect contraints
on all defined dependencies. If a prerelease constraint is detected,
automatically enable prerelease resolution.
This pull request adds an enhancement to the internal Bundler class
to cache solution sets. This prevents Vagrant from generating a
solution for configured plugins on every run. Modifications to
the configured plugin list (global or local) will result in the
cached solution being invalidatd and resolved again.
Also included is the removal of the GEMRC modifications required
for Windows.
In recent Rubies the first dependency to satisfy the constraint will
be used regardless if higher versions are available in subsequent
sources. Move custom source to start of list when resolving plugins
to provide desired behavior.
