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
The implementation of the `CSV` shortcut method is broken in Ruby 3
for calls that look like this:
```ruby
CSV(write_stream, col_sep: "|", headers: headers, write_headers: true) do |csv|
...
end
```
The above will result in the following error when the `CSV` method attempts to pass
on arguments to `CSV#instance`:
```
ArgumentError: wrong number of arguments (given 2, expected 0..1)
```
The issue is due to the changes in Ruby 3 relating to positional & keyword arguments.
This commit updates the `CSV()` shortcut implementation to work with Ruby 3, and also
updates the documentation for the shortcut method.
https://github.com/ruby/csv/commit/310dee45fa
It's for Ractor. If you want to use the built-in converters, you
should call Ractor.make_shareable(CSV::Converters) and/or
Ractor.make_shareable(CSV::HeaderConverters).
https://github.com/ruby/csv/commit/b0b1325d6b
I am not sure why this flag was turned off (it wasn't explained in my commit message in 0365dc852767ae589376a7aad1fb129738e408b0 or in my PR in #4411).
Whatever the reason, without `default_ignores` turned on, most default CI configurations will immediately fail, as they most likely vendor and cache their dependencies under `vendor`, which will cause standard to run against all the vendored gems and (most likely) fail. I think we should remove this before this feature is released.
https://github.com/rubygems/rubygems/commit/677f74be48
David Rodríguez
Yusuke Endoh
Jenny Shen
Jean Boussier
Daniel Colson
rm155
Sutou Kouhei
Anthony Hernandez
Kenta Murata
Joakim Antman
Vince
Yuki Nishijima
rm155
Tiago
Olle Jonsson
Justin Searls
Hiroshi SHIBATA