We sometimes check assertions on lockfile contents, which involves
comparing a reasonably long string. Sometimes RSpec is not able to show
the part of the string that's actually different, making it hard to
figure out the issue.
Configuring this setting should fix the issue in most cases.
https://github.com/rubygems/rubygems/commit/5ad8ee499e
This allows the file to be created without copying permissions
from Bundler's installation source. The previous behaviour was
noticed after installing Ruby through brew, and using bundle
init, which yielded a read-only Gemfile.
https://github.com/rubygems/rubygems/commit/839a06851d
After recent musl support was added, Bundler started hanging in musl
platforms. I identified the issue where valid candidates were being
filtered out because their platform was specified as a string, and thus
`Gem::Platform.match_spec?` which under the hood ends up calling
`Gem::Platform#===` would return `nil`, because it does not support
comparing platforms to strings.
In particular, `Bundler::EndpointSpecification`'s platform coming from
the API was not instantiated as a `Gem::Platform`, hence the issue.
Also, this spec surfaced another issue where a bug corrected in
`Gem::Platform#match_platforms` had not been yet backported to Bundler.
So this commit also backports that to get the spec green across RubyGems
versions.
Finally, the fix in `Bundler::EndpointSpecification` made a realworld
spec start failing. This spec was faking out `rails-4.2.7.1` requirement
on Bundler in the `Gemfile.lock` file to be `>= 1.17, < 3` when the real
requirement is `>= 1.17, < 2`. Due to the bug in
`Bundler::EndpointSpecification`, the real requirement provided by the
compact index API (recorded with VCR) was being ignored, and the
`Gemfile.lock` fake requirement was being used, which made the spec
pass. This is all expected, and to fix the issue I changed the spec to
be really realworld and don't fake any Bundler requirements.
https://github.com/rubygems/rubygems/commit/faf4ef46bc
Recently a changed was introduced to update the resolver platforms after
it has been created, in order to remove the "ruby" platform from it if
it's to be removed from the lockfile. However, it did not update the
`@resolving_only_for_ruby` instance variable in that case, so the
resolver was not properly doing the right thing anymore.
To fix this, I tweaked the code to restore not changing resolver
platforms after the resolver has been instantiated.
https://github.com/rubygems/rubygems/commit/8fbc30a1d0
When `--conservative` is passed, explicit unlocks are set for top level
gems via `@unlock[:gems]`, so that only those particular gems are
allowed to be updated.
When we compute the "base resolve" from the lockfile (the set of gems
whose versions should be kept pinned by the resolver), we always exclude
gems explicitly unlocked through `@unlock[:gems]` from it. This is done
by the `converge_specs` method.
However, the `converge_specs` method is also used for figuring out
additional lower bound requirements from the lockfile. But in this case,
even if gems are explicitly unlock in `@unlock[:gems]`, we still want to
add the additional requirement, so that gems are not downgraded by the
resolver.
So the solution is to move the line filtering out gems in
`@unlock[:gems]` from the `converged_specs` method out of that method,
so that it only applies for computing the "base resolve", but not the
addtional lower bound requirements.
https://github.com/rubygems/rubygems/commit/405119bd7b
This is a regression from a change intended to raise errors when user
puts a gem under an incorrect source in the Gemfile by mistake. To fix
the issue, we revert the change that caused it and implement it in a
different way that restores the resolver independency from real
specifications. Now it deals only with names and versions and does not
try to materialize anything into real specifications before resolving.
https://github.com/rubygems/rubygems/commit/d2bf1b86eb
Do dependency filtering and materialization in one step. Before,
dependency filtering would not consider ruby metadata so it would
discard variants that end up not being materializable in the end.
https://github.com/rubygems/rubygems/commit/0c0d40d417
Co-authored-by: Ian Ker-Seymer <ian.kerseymer@shopify.com>
Previously if `~/.bundle/cache/compact_index/rubygems.org.*/version`
were owned by root with read-only access, `bundle install` would fail
with a misleading error message. For example:
```
There was an error while trying to write to `/tmp/bundler-compact-index-20220711-1823-npllre/versions`. It is
likely that you need to grant write permissions for that path.
```
This happened because the EACCESS error was caught by
`SharedHelpers.filesystem_access`, which makes it look like the target
directory is at fault instead of the source.
We can't simply drop this guard because that causes the opposite
problem: the permission error appears to come from the source instead of
the target, since `CompactIndexClient::Cache#lines` also wraps read
access errors.
Instead, bring a minimal implementation of `FileUtils.cp` and nest calls
to `SharedHelpers.filesystem_access` properly.
https://github.com/rubygems/rubygems/commit/320822c070
Co-authored-by: Stan Hu <stanhu@gmail.com>
Hiroshi SHIBATA
David Rodríguez
Victor Gama
Nobuyoshi Nakada
Mike Dalessio
shields
Aleksandr Varnin
Takuya Noguchi
moe