Previously, the command string to be used for the shell command
was first generated and then split using shellsplit. This change
reverts the current behavior as it breaks if the value of remote
contains a space.
https://github.com/rubygems/rubygems/commit/6649ee10b0
Prior to this patch, if I ran:
ruby setup.rb --destdir /foo
Then Bundler files would be written into /foo/foo, because destdir was
being prepended, even though `bundler_spec.bin_dir` already included
destdir.
https://github.com/rubygems/rubygems/commit/9e857ffb52
The last_communicated timestamp is for HTTP persistent connection, to
decide whether the current TCP connection may be reused for the
subsequent requests or not. Naturally, the timer must be reset if the
connection is recreated since it is no longer relevant.
https://github.com/ruby/net-http/commit/0a013de42d
Calling `Bundler.definition.specs` will memoize materialized specs.
However, requiring `bundler/setup` will end up materializing the same
set of specs, but not memoize them.
This change makes things consistent.
https://github.com/rubygems/rubygems/commit/e4c2b52824
So that it loads a consistent version of the library and `rubygems` is
never affected by gem activation conflicts related to `tsort`.
Getting CI green required updating one `bundler` spec, because `tsort`
is no longer loaded by `bundle clean` until after `BUNDLE_PATH` has been
changed, so to ensure it is found, it needs to be installed under
`BUNDLE_PATH` as well (which will be different from the global system
path on Bundler 3, meaning installing `tsort` to the global system path
is not enough there). This spec workaround can be removed once we also
vendor `tsort` inside `bundler`.
https://github.com/rubygems/rubygems/commit/d326880999
Even if it's newer than the running versions. Dev versions are not
released to rubygems.org, so the warning message suggests a command that
doesn't work. And dev versions are currently non deterministic
(2.3.0.dev can be many different versions), so the warning doesn't
really make sense at the moment.
https://github.com/rubygems/rubygems/commit/6f31af27ef
Now the formatter configuration is per Ractor. DefaultFormatter is used
if not set.
DefaultFormatter#message_for is now a class method to allow sub-Ractors
to call the method.
https://github.com/ruby/error_highlight/commit/9fbaa8ab7c
We require things inline or autoload them for efficiency and to avoid as
much as possible conflicting with user's choice of gems.
But I removed the require and observed no deadlocks when activating
gems.
https://github.com/rubygems/rubygems/commit/7d6333e842
Some crucial information to ease maintainers work, like the advice of
upgrading rubygems and bundler, was one step away from the issue
template, making it easier for some users to miss.
Now all relevant information is written directly in the bug report
template.
We can skip most stuff in `Gem::RemoteFetcher#download`, and use
`Gem::RemoteFetcher#update_cache_path` directly.
This has the benefit of allowing us to remove some workarounds to
support several rubygems versions, but also allows us to pass the target
folder where the gem should be downloaded directly and skip the logic
inside `Gem::RemoteFetcher#download` to infer the cache path. This will
be useful later to fix some issues with the `global_gem_cache` feature
flag.
https://github.com/rubygems/rubygems/commit/8fe74a77e4
These methods rescue a constant defined by `rubygems/remote_fetcher`,
so they should technically require it.
The require is provided by `gem_remote_fetcher` anyways but I was
running a unit spec that stubs that method, so I was getting an
undefined constant error hiding another error.
https://github.com/rubygems/rubygems/commit/8bedae4034
Extract final cache path to a variable and pass that to `download_gem`.
It actually fits better the parameters documentation since it's the
final directory where the downloaded gem will be placed.
https://github.com/rubygems/rubygems/commit/1429db6a04
When `install_with_build_args` was added in
be96283985,
there were two versions of the method: the default version in the base class that still
used the locking `with_build_args`, and an override in the `Future`
class (for Rubygems 2.0 and up) that yielded without calling
`with_build_args`.
The `with_build_args` version of the method was removed in
8a5b71e3e8
while removing a bunch of the old Rubygems compatibility code.
This commit removes `with_build_args`, since it no longer appears to be
used (the build args are passed as a keyword argument to
`spec.source.install` instead, since
be96283985).
The commit also removes `install_with_build_args` and the conditional
around it, since the method wasn't doing anything different than
`install`, and it had a comment that was no longer accurate.
https://github.com/rubygems/rubygems/commit/ba543a60eb
Nicholas Lee
Hiroshi SHIBATA
haruuzion
David Rodríguez
Alyssa Ross
Nobuyoshi Nakada
Kazuki Yamaguchi
Carlos Palhares
180909
Frederik Dudzik
Frederik Dudzik
Yusuke Endoh
Jenny Shen
Jean Boussier
Daniel Colson