Because bundler needs to support older versions of rubygems, we can't
actually rely on Gem::CIDetector (yet - in a year or so they might be
able to consolidate, if they don't change futher). So we're copying it
into the Bundler:: namespace, and enforcing that they stay completely in
sync with a test. No other tests are needed, since Gem::CIDetector is
already tested, and this is and will remain identical.
abc67f0da1
Generally the removed message is very similar, but often it needs to
specify that the feature has "been removed" instead of "will be
removed", or "been deprecated". And a few chunks of text needed more
substantial updates. And a number of them seemed to have been carefully
crafted to make sense in either context, so I left those alone.
8d42cf9104
We lock the checksum for each resolved spec under a new CHECKSUMS
section in the lockfile.
If the locked spec does not resolve for the local platform, we preserve
the locked checksum, similar to how we preserve specs.
Checksum locking only makes sense on install. The compact index
information is only available then.
bde37ca6bf
Recent bugs fixed made me realize we were relying on state too much
here. We only need to keep incomplete specs to be able to expire them
and retry resolution without them locked. If we use a separate class, we
can do that more transparently and handle them just like we handle
"missing specs".
It's explicitly loaded when monkeypatching RubyGems, which we do very
early. So neither autoloading it, nor explicitly loading it anywhere
else is necessary.
fbc7a57161
If BUNDLE_PATH is configured to a symlinked path, installing gems with
symlinks would crash with an error like this:
```
Gem::Package::SymlinkError: installing symlink 'man/man0/README.markdown' pointing to parent path /usr/home/stevewi/srv/mail/lib/tools/.vendor/ruby/3.1.0/gems/binman-5.1.0/README.markdown of /srv/mail/lib/tools/.vendor/ruby/3.1.0/gems/binman-5.1.0 is not allowed
```
This commit fixes the problem by changing the bundle path to be the
realpath of the configured value, right after we're sure the path has
been created.
3cd3dd142a
This is hiding a real bundler issue as a "network error". It's more
helpful to get a proper bug report, with stack trace and so on.
So stop re-raising errors when evaluating unmarshaled responses as
network errors, and only raise Marshal errors when the Marshal format is
invalid, not whenever marshalled gemspecs can't be loaded because that
may hide actual client errors, like missing `YAML` constants.
05ea907e1c
Ruby 1.9.2 removed "." from LOAD_PATH for robustness and security reasons.
This code was introduced by 56fc830e19 commit
to helping users understand the issue and had a guard condition to include the message for `RUBY_VERSION >= "1.9"`.
However, the guard condition was removed as part of the "Ruby version leftover" cleanup by
8c9cf76e41
Ruby 1.9 development was ended a long time ago and this message is not useful anymore.
a23609b15a
