The generic Ruby platform was getting unconditionally added in
truffleruby, preventing resolution in situations where there's no
generic ruby version (sorbet-static). Instead, the generic platform
should be considered per dependency, not globally.
a96afc5351
If you have
```
gem "rails", git: "https://github.com/rails/rails"
```
and then explicitly pin to an older ref, like
```
gem "rails", git: "https://github.com/rails/rails", ref: "99bacb5aa8"
```
Then `bundle install` fails, because locked sources fail to be updated
to use the new source.
This commit fixes the problem by making sure get their source properly
replaced.
5de8c2e0cf
Instead, remove them anytime we find dependencies don't match the
lockfile for a platform, and then add them back after resolution if
they ended up being valid.
220bd77887
Instead of doing an explicit pass to preserve the source from the
Gemfile when it's a `Source::Gemspec`, add a special case to our generic
source replacement method.
20c8c42380
This message is printed when running `bundle lock --add-platform`. This
command affects the lockfile, not the gemfile, and I think it's better
to use "You are adding" rather than "You added", because the addition is
happening during the current invocation (as opposed to other log
messages that talk about a change made to the Gemfile prior to running
the command).
aba1e55f5b
When working with our repository on JRuby locally, I get the following
changes when running `bin/rake setup` in all of our lockfiles
```diff
diff --git a/tool/bundler/dev_gems.rb.lock b/tool/bundler/dev_gems.rb.lock
index 74550b2a40 100644
--- a/tool/bundler/dev_gems.rb.lock
+++ b/tool/bundler/dev_gems.rb.lock
@@ -66,6 +66,7 @@ PLATFORMS
java
ruby
universal-java
+ universal-java-22
x64-mingw-ucrt
x86-linux
x86_64-darwin
```
This is inconvenient, so I applied the same strategy we already use on
non JRuby implementations to not add the current platform to the
lockfile if a less specific platform is already there.
812b9cd1e8
There's no reason to call `converge_specs` when adding additional
lower bound requirements to prevent downgrades, and it actually causes
the extra requirements to be missed sometimes.
Loop over the originally locked specs directly, adding the additional
precaution of not adding the requirement if the Gemfile dependency has
changed and it no longer matches the locked spec.
5154506912
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.
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.
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.
64d84ad7d8
When converging locked specifications to select the ones that should be
preserved while resolving, we can avoid having to do a second pass to
ignore the ones that have been explicitly unlocked.
411742703e