Closes https://github.com/rubygems/rubygems/issues/7076
Bundler will now use the same (shared) remote fetcher instance that
RubyGems uses.
This will allow installs to use a shared connection pool, which
represents a significant performance improvement on a clean install.
cd87b40fe1
These are necessary to get the tests passing with LibreSSL 3.8.1+,
which dropped support for TLSv1.0 and TLSv1.1 for security reasons.
This updates the tests to use TLSv1.2 on OpenBSD. This is only
strictly necessary on OpenBSD 7.4+, but it will work fine in previous
versions as well.
32707b2db5
Currently, you can install multiple versions of the same gem just fine:
```
$ gem install simplecov:0.19.0 simplecov:0.22.0
Fetching simplecov-0.19.0.gem
Successfully installed simplecov-0.19.0
Parsing documentation for simplecov-0.19.0
Installing ri documentation for simplecov-0.19.0
Done installing documentation for simplecov after 0 seconds
Fetching simplecov-0.22.0.gem
Successfully installed simplecov-0.22.0
Parsing documentation for simplecov-0.22.0
Installing ri documentation for simplecov-0.22.0
Done installing documentation for simplecov after 0 seconds
2 gems installed
```
But to uninstall both of them, you need to run the equivalent uninstall
command twice:
```
~$ gem uninstall simplecov:0.19.0 simplecov:0.22.0
Successfully uninstalled simplecov-0.22.0
~$ gem uninstall simplecov:0.19.0 simplecov:0.22.0
Gem 'simplecov' is not installed
Successfully uninstalled simplecov-0.19.0
```
This resolves that problem by using the gem's full name (which includes
the version) when tracking which ones have already been uninstalled so
when it gets to the second version listed it doesn't think it was
already uninstalled.
d96101b753
The `lock` command is specifically designed to manage the lockfile, so
running it should take precedence over any "frozen" setting.
Besides that, "frozen" is not specifically designed as "lockfile cannot
be updated" but as "installation of gems should be prevented if gemfile
is not in sync with the lockfile".
The lock command does not install any gems and preserves the property of
the lockfile being in sycn with its gemfile, so I think frozen should
not influence it.
The current behavior is quite confusing when frozen is set. On an app
where rubocop can get lockfile updates
```
$ bundle lock --update rubocop
Writing lockfile to /path/to/Gemfile.lock
```
Completely silent, it makes you think that it has written the lockfile,
but still no updates.
In verbose mode, it gives a bit more information, but still confusing
and unexpected, and does not change the lockfile:
```
$ bundle lock --update rubocop --verbose
Running `bundle lock --update "rubocop" --verbose` with bundler 2.4.20
Frozen, using resolution from the lockfile
Writing lockfile to /path/to/Gemfile.lock
```
With this commit, it updates the lockfile as expected.
1d501ae8ea
I couldn't find a cross-platform way to check "can I create this directory?"
So I removed that, and went back to the original simpler logic of
"if the directory is writable, use it."
3aa86a56db
