| Age | Commit message (Collapse) | Author |
|---|
|
https://github.com/rubygems/rubygems/commit/376e4ec8c7
Co-authored-by: David Rodríguez <2887858+deivid-rodriguez@users.noreply.github.com>
|
|
`Bundler::SpecSet#<<`
https://github.com/rubygems/rubygems/commit/aee50b31db
|
|
https://github.com/rubygems/rubygems/commit/380c95ce05
|
|
This will help centralize wheel platform selection logic eventually
Signed-off-by: Samuel Giddins <segiddins@segiddins.me>
|
|
platforms
https://github.com/rubygems/rubygems/commit/c39d2f84fd
|
|
incompatible
https://github.com/rubygems/rubygems/commit/282e4a8593
|
|
If both a native and a generic version are locked, but the native
version is incompatible with the running Ruby, Bundler will still keep
the native version in the lockfile, since it could be potentially useful
when using other rubies.
However, when `bundle update` is run, this was not the case because the
locked native gems were not using the right source when materializing.
They were using the lockfile source instead of the Gemfile source, and
that meant they could not be found when materializing, because the
lockfile source always uses local mode so does not see them.
The effect of this was normally that they were incorrectly removed from
the lockfile and a strange "this spec has been possibly yanked" was
printed in verbose mode. However, in certain situations (i.e., when the
generic gem would bring extra dependencies), it could also make `bundle
update` crash.
The solution is, when adding this extra locked specs to the result after
resolving, maybe sure they inherit the source from the resolved specs,
so they can be found when materializing.
`bundle install` did not have the issue because it passes locked specs
to the resolver, and assigns the right source to them in
`Definition#converge_locked_specs`.
https://github.com/rubygems/rubygems/commit/91ce881fda
|
|
https://github.com/rubygems/rubygems/commit/458fa5dc4c
|
|
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.
https://github.com/rubygems/rubygems/commit/220bd77887
|
|
anything
https://github.com/rubygems/rubygems/commit/9fd92ade54
|
|
We have a flaky failure where to equal Bundler specs sneak into the same
SpecSet. This seems like a vector where that could happen so trying this
in case it fixes the flaky.
https://github.com/rubygems/rubygems/commit/a33aeb3c4d
|
|
https://github.com/rubygems/rubygems/commit/55af558124
|
|
https://github.com/rubygems/rubygems/commit/a3f365bbaa
|
|
And make the current `materialize_strictly` private.
https://github.com/rubygems/rubygems/commit/3fc2129147
|
|
For better debuggability.
https://github.com/rubygems/rubygems/commit/21d252fa7a
|
|
lockfile unless necessary
Even if they don't match the current Ruby version, they could still work
in other rubies. So it's better to keep them.
https://github.com/rubygems/rubygems/commit/9a3e583b0c
Notes:
Merged: https://github.com/ruby/ruby/pull/12568
|
|
Just for consistency, since all the other methods in this class that
receive an array of dependencies use `deps`.
https://github.com/rubygems/rubygems/commit/eca1341950
Notes:
Merged: https://github.com/ruby/ruby/pull/12568
|
|
https://github.com/rubygems/rubygems/commit/a76fd6d3bf
Notes:
Merged: https://github.com/ruby/ruby/pull/12568
|
|
https://github.com/rubygems/rubygems/commit/9ea1539b08
|
|
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.
https://github.com/rubygems/rubygems/commit/411742703e
|
|
As long as some spec in the materialization is complete.
https://github.com/rubygems/rubygems/commit/9a673b0bbb
|
|
https://github.com/rubygems/rubygems/commit/3041b3d784
|
|
This gives more flexibility to allow further improvements.
https://github.com/rubygems/rubygems/commit/f11a890f5e
|
|
most_specific_locked_platform
So there's no need to pass it around in so many places.
https://github.com/rubygems/rubygems/commit/784ab7481b
|
|
https://github.com/rubygems/rubygems/commit/a2bb68a29b
|
|
https://github.com/rubygems/rubygems/commit/e1caeecdf8
|
|
https://github.com/rubygems/rubygems/commit/6a6041d073
|
|
https://github.com/rubygems/rubygems/commit/bc2537de71
|
|
https://github.com/rubygems/rubygems/commit/43c0c41c6b
|
|
|
|
When resolving on truffleruby, and multiple platforms are included in
the lockfile, Bundler will not respect existing platforms, but always
force ruby variants. That means removal of existing version specific
variants, introducing lockfile churn between implementations.
To prevent this, we introduce the distinction between
`Dependency#force_ruby_platform`, only settable via Gemfile, and
`Dependency#default_force_ruby_platform`, which is always true on
truffleruby for certain dependency names. This way, when resolving
lockfile gems for other platforms on truffleruby, we keep platform
specific variants in the lockfile.
However, that introduces the problem that if only platform specific
variants are locked in the lockfile, Bundler won't be able to
materialize on truffleruby because the generic variant will be missing.
To fix this additional problem, we make sure the generic "ruby" platform
is always added when resolving on truffleruby.
|
|
* `bundle exec` assigns `Gem::Specification.all` to the set of specs
known to Bundler (a `Bundler::SpecSet`).
* `gem uninstall` recently started calling `#delete` on the set of specs
stored in `Gem::Specification#all`. This, in RubyGems, is just an
array of specs, so has a `#delete` method that receives a single
element.
* However, at some point I added a `SpecSet#delete` method that takes an
array of specs, breaking the "Array-like" contract and making `gem
uninstall` break when run in a `bundle exec` context.
The fix is to make `Bundler::SpecSet#delete` handle being given a single
spec.
https://github.com/rubygems/rubygems/commit/e3acb7b01d
|
|
https://github.com/rubygems/rubygems/commit/bcbbff5149
|
|
Instead of having to do a complete pass after resolve.
To do this, we add to the ruby group all the platform specs with the
same dependencies as the ruby specs.
https://github.com/rubygems/rubygems/commit/e50415f2a6
|
|
cache
Even if all gems are properly installed and no resolve is needed, we
recently started always reading all packages in `vendor/cache` and
extracting specifications from them.
This commit fixes the problem by longer making considering cached specs
the default and only enable them when a resolve is actually needed.
https://github.com/rubygems/rubygems/commit/edeb2c42bf
|
|
If `cache_all_platforms` setting is enabled, the secondary source was
no longer considering cached gems.
That means that if the remote secondary source has removed its gems,
then this was now resulting in an error while before the previously
cached gem from the source would still be used.
This commit restores previous behavior.
https://github.com/rubygems/rubygems/commit/2d2cd00255
|
|
musl vs gnu case
This case is for not locking things like `arm-darwin-23` when the
lockfile already includes `arm-darwin`, so that we don't infinitely keep
redundant versioned platforms in the lockfile when not necessary.
We detect this with `Gem::Platform#===`. For example,
`Gem::Platform.new("arm-darwin-23") === Gem::Platform.new("arm-darwin")`
but they're not `==`.
However, in the case of `-musl` vs `-gnu`, those act as the platform
"version", but `===` is not commutative for them. This is explained in
`===` docs.
We only want to exclude the local platform in situations when
`Gem::Platform#===` is actually commutative.
https://github.com/rubygems/rubygems/commit/8099c4face
|
|
https://github.com/rubygems/rubygems/commit/235f7b4266
|
|
If two platform specific variants have different dependencies, then
resolution may fallback to the non platform specific variant. However,
the platform specific variants that have the same dependencies as the
non specific one can still be kept.
Do a pass to complete those after resolution.
|
|
https://github.com/rubygems/rubygems/commit/a8b547c6b1
|
|
https://github.com/rubygems/rubygems/commit/880a4eae7f
|
|
https://github.com/rubygems/rubygems/commit/1d15d8a8ff
|
|
https://github.com/rubygems/rubygems/commit/41f9b4d940
|
|
|
|
If a platform specific variant would not match the current Ruby, we would still be
considering it compatible with the initial resolution and adding its
platform to the lockfile, but we would later fail to materialize it for
installation due to not really being compatible.
Fix is to only add platforms for variants that are also compatible with
current Ruby and RubyGems versions.
https://github.com/rubygems/rubygems/commit/75d1290843
|
|
Since we started locking the specific platform in the lockfile, that has
created an annoying situation for users that don't develop on Linux.
They will create a lockfile on their machines, locking their local
platform, for example, darwin. But then that lockfile won't work
automatically when deploying to Heroku for example, because the lockfile
is frozen and the Linux platform is not included.
There's the chance though that resolving against two platforms (Linux +
the local platform) won't succeed while resolving for just the current
platform will. So, instead, we check other platform specific variants
available for the resolution we initially found, and lock those
platforms and specs too if they satisfy the resolution.
This is only done when generating new lockfiles from scratch, existing
lockfiles should keep working as before, and it's only done for "ruby
platforms", i.e., not Java or Windows which have their own complexities,
and so are excluded.
With this change, we expect that MacOS users can bundle locally and
deploy to Heroku without needing to do anything special.
https://github.com/rubygems/rubygems/commit/5f24f06bc5
|
|
https://github.com/rubygems/rubygems/commit/53e0490b55
|
|
https://github.com/rubygems/rubygems/commit/5f90a43635
Co-authored-by: Martin Emde <martin.emde@gmail.com>
|
|
https://github.com/rubygems/rubygems/commit/40989271dd
|
|
the ruby platform
https://github.com/rubygems/rubygems/commit/7c50064c3c
|
