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
Parts of the stdlib which have been externalized but are still
included within Ruby introduce issues when pinning Vagrant's
dependencies to resolve plugin installs. When determining
Vagrant's dependency list prior to solution generation, check
the specification and ignore any default gems to prevent
pinning versions that are not actual dependencies.
When starting up, and before any loading, find our current
specification and activate all the internal dependencies
while also collecting the activated specifications. Store
these for later use when doing plugin resolutions. We bypass
the builtin list when running in bundler since they will
still show up as not activated, but we use the entire list
regardless.
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 includes updates for resolving all warnings provided by Ruby
for deprecations and/or removed methods. It also enables support
for Ruby 2.7 in the specification constraint as all 2.7 related
warnings are resolved with this changeset.
During a plugin install, if the plugin is already installed and
activated, no specification will be returned as there was nothing
new installed. In this situation, look for the requested plugin
within the activated specifications. If it is found, then proceed
since the plugin is installed. If it is not found, return an error.
Sets prerelease on the request set based on Vagrant's version. This
allows installing plugins which may include a vagrant version constraint
when running on a development version without needing to a manual local
installation of the gem.
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.
When installed outside of the official installer and not running
within a bundler environment, properly activate core dependencies
and properly enforce constraints.
Prior to this commit, when Vagrant attempted to use the Gem library, it
would attempt to pass in a gemrc through an environment variable that
the rubygems library would try to split and parse. This is normally
fine, as the method in question would return empty if that file did not
exist. However if the user had a file that matches the drive that
Vagrant was installed on, rubygems would fail saying the folder was not
a file (or a gemrc, in this case).
This commit works around that by instead configuring the gemrc location
through ruby with `Gem.configuration`.
Related rubygems issue
[#2733](https://github.com/rubygems/rubygems/issues/2733)
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.
If a user provides the gem version using an explicit version or a
constraint, the update action should honor that constraint and not
simply replace it with an unbound constraint.
This also removes system plugin specifications from being matched
and preferred which prevents updates and can result in unexpected
downgrades when running the update.
Installation solution sets in 2.2.5 can end up out of order (not seen
in 2.3.1) causing LoadErrors when the specification is in the solution
set during validation. This detects the missing spec within the solution
and if found will move spec to the start of the solution set and retry
solution activation.
Refactors reusable actions into isolated methods. Supports installation/removal
without activation to prevent unintended conflicts during upgrades and cleanup.
Introduced custom resolver set to handle multiple installed versions of gems
which enables proper cleanup.
