| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
`Bundle.defintion`.
Prior to this commit, `bundle add GEM_NAME` updated the lockfile,
but `bundle remove GEM_NAME` left GEM_NAME in the lockfile.
By invalidating the cached `Bundle.definition`, the existing code
handles that without a problem.
https://github.com/rubygems/rubygems/commit/aa0794d6a9
|
|
|
|
|
|
|
|
|
|
|
| |
The installer is actually rewriting the spec's full gem path to be the
one of the newly installed gem, however the accessor was not properly
working for `StubSpecification` instances, and default gems are always
of this type, because they are always present locally.
Fix the accessor to properly update the underlying full specification.
https://github.com/rubygems/rubygems/commit/efa41babfa
|
|
|
|
|
|
|
|
| |
This change was never covered with a spec, and we have recently covered
the case of partially deleted gems with specs and it works fine
(installation is "auto-healed").
https://github.com/rubygems/rubygems/commit/6e66ee4235
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`YAML::PrivateType`
This issue was not detected because when all traces of old YAML parser
and emitter `Syck` were removed, this null-type.gemspec.rz marshalled
gemspec was updated to no longer load `YAML::Syck::PrivateType` but load
`Psych::PrivateType` instead.
However, realworld old marshalled gemspecs still use the
`YAML::PrivateType` constant, so this commit replaces the gemspec to be
the real pry-0.4.7 marshalled gemspec, so that it catches this issue.
https://github.com/rubygems/rubygems/commit/51b330b8d2
|
|
|
|
|
|
|
|
|
|
|
|
| |
This old bug used to affect the `rubyforge_project` field in serialized
gemspecs. However, this field has been removed and it's no longer
present in marshaled loaded gemspecs.
So, while the constant is still present in these marshalled gemspecs and
we still need to make sure it exists, we no longer need to clean it up
from the loaded data.
https://github.com/rubygems/rubygems/commit/09df18e522
|
|
|
|
|
|
|
|
|
|
|
| |
Generally this warning is skipped for gemspec development dependencies.
I think because it's common to override them in the Gemfile to change
the source, for example.
But the order of conditions was not correct and the warning was still
being printed in one case.
https://github.com/rubygems/rubygems/commit/da9d1d6a3f
|
|
|
|
|
|
|
|
| |
This alternative really uses only the Gemfile, and can never end up
being absurd, because it will never be suggested when there's no
lockfile, and it suggests deleting the lockfile.
https://github.com/rubygems/rubygems/commit/5d154dd50e
|
|
|
|
|
|
|
|
|
|
| |
Treats:
::copy_entry
::copy_file
::copy_stream
::mv
https://github.com/ruby/fileutils/commit/d6d7e5330d
|
|
|
|
| |
https://github.com/rubygems/rubygems/commit/2d99277328
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
https://github.com/rubygems/rubygems/commit/3cd3dd142a
|
|
|
|
| |
https://github.com/rubygems/rubygems/commit/f5dd5204ca
|
|
|
|
|
|
|
|
|
|
| |
Apparently old versions of MacOS would set `GEM_HOME` to a `/System`
folder, and trying to create a file there raises `Errno::EROFS`.
We ignore the error. Any permission issues should be better handled
further down the line.
https://github.com/rubygems/rubygems/commit/ef90c071d0
|
|
|
|
|
|
|
|
|
|
| |
This kind of error can happen when setting `GEM_HOME` to a path
under MacOS System Integrity Protection.
We ignore the error. Any permission issues should be better handled
further down the line.
https://github.com/rubygems/rubygems/commit/174cb66863
|
|
|
|
| |
https://github.com/rubygems/rubygems/commit/a7f81cc7ee
|
|
|
|
|
|
| |
It's already done before.
https://github.com/rubygems/rubygems/commit/49d28cfde5
|
|
|
|
|
|
| |
configured
https://github.com/rubygems/rubygems/commit/9f3b21192d
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
removed
Instead of guessing on the culprit.
We actually have a helper, `Bundler.rm_rf`, with exactly the behavior
that we want:
* Allow the passed folder to not exist.
* No exception swallowing other than that.
https://github.com/rubygems/rubygems/commit/5fa3e6f04a
|
|
|
|
|
|
| |
(https://github.com/ruby/fileutils/pull/76)
https://github.com/ruby/fileutils/commit/27a3c376c7
|
|
|
|
| |
https://github.com/ruby/timeout/commit/f3a31abdfb
|
|
|
|
| |
https://github.com/ruby/timeout/commit/5153ae9cad
|
|
|
|
| |
https://github.com/ruby/timeout/commit/01c44b591f
|
|
|
|
| |
https://github.com/ruby/timeout/commit/9a9b03b44c
|
|
|
|
| |
https://github.com/ruby/timeout/commit/f69f954a94
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This maybe isn't probably isn't the best approach, but it will allow
`Fiddle::Terminfo.curses_dl` to work. I documented more details about
this in an issue on fiddle: https://github.com/ruby/fiddle/issues/107
It is probably better to deal with it there. But this is workaround is
simpler.
FYI: `reline` itself seems to be working just fine for me _without_
loading ncurses. But I wanted to be able to use `Reline::Terminfo` for
my own projects. :)
https://github.com/ruby/reline/commit/fd4bdb35e2
|
|
|
|
| |
https://github.com/rubygems/rubygems/commit/84b163e804
|
|
|
|
|
|
| |
(https://github.com/ruby/fileutils/pull/75)
https://github.com/ruby/fileutils/commit/a4da433443
|
|
|
|
|
|
| |
requirements
https://github.com/rubygems/rubygems/commit/b69e1e9374
|
|
|
|
|
|
| |
(https://github.com/ruby/fileutils/pull/74)
https://github.com/ruby/fileutils/commit/956b345ceb
|
|
|
|
|
|
| |
(https://github.com/ruby/fileutils/pull/73)
https://github.com/ruby/fileutils/commit/ff49055f8a
|
|
|
|
|
|
| |
(https://github.com/ruby/fileutils/pull/72)
https://github.com/ruby/fileutils/commit/db612c5e22
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Exception#detailed_message
I am asking did_you_mean to use Exception#detailed_message to add
"Did you mean?" suggestion instead of overriding #message method.
https://github.com/ruby/did_you_mean/pull/177
Unfortunately, the change will affect Gem::UnknownCommandError, which
excepts did_you_mean to override #message method.
This PR absorbs the change of did_you_mean.
Gem::CommandManager now calls #detailed_message method to get a message
string with "Did you mean?" suggestion from an exception.
https://github.com/rubygems/rubygems/commit/8f104228d3
|
|
|
|
|
|
|
| |
RDoc overrides class name by the assigned name unexpectedly when
assigned using a qualified class path.
https://github.com/ruby/net-http/commit/a7bded0407
|
|
|
|
|
|
| |
(https://github.com/ruby/fileutils/pull/71)
https://github.com/ruby/fileutils/commit/39772bccca
|
|
|
|
|
|
| |
`HTTPServerException` is the name deprecated since years ago.
https://github.com/ruby/net-http/commit/b3028fef5a
|
|
|
|
|
|
| |
fix https://github.com/ruby/reline/pull/428
https://github.com/ruby/reline/commit/dae9eca323
|
|
|
|
|
|
| |
(https://github.com/ruby/tempfile/pull/10)
https://github.com/ruby/tempfile/commit/a5e53aa82a
|
|
|
|
|
|
| |
This gem exposes no executables.
https://github.com/ruby/tempfile/commit/07fde5fe14
|
|
|
|
| |
https://github.com/rubygems/rubygems/commit/125415593ead9ab69a9f0bb5392c9d7ec61b1f51
|
|
|
|
|
|
|
|
|
|
| |
warning. (https://github.com/ruby/did_you_mean/pull/172)
```
did_you_mean/formatters/verbose_formatter.rb:5: warning: `frozen_string_literal' is ignored after any tokens
```
https://github.com/ruby/did_you_mean/commit/531760f323
|
|
|
|
|
|
| |
* It's already checked inside #interrupt.
https://github.com/ruby/timeout/commit/5f43254f81
|
|
|
|
|
|
|
| |
* So it is trivially correct.
* Performance seems the same overall.
https://github.com/ruby/timeout/commit/5e0d8e1637
|
|
|
|
| |
https://github.com/ruby/timeout/commit/4baee63b9b
|
|
|
|
| |
https://github.com/ruby/timeout/commit/2bafc458f1
|
|
|
|
| |
https://github.com/ruby/irb/commit/af99c01b0d
|
|
|
|
| |
https://github.com/ruby/set/commit/71a876ae81
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On `rails/rails` repository Gemfile, running the following script
```
# script.rb
require "bundler/setup"
```
#### Before
```
➜ rails git:(main) ✗ BUNDLER_VERSION=2.4.0.dev ruby-memory-profiler --pretty --no-detailed --allocated-strings=0 --retained-strings=0 script.rb
Total allocated: 24.37 MB (207937 objects)
Total retained: 2.98 MB (34152 objects)
```
#### After
```
➜ rails git:(main) ✗ BUNDLER_VERSION=2.4.0.dev ruby-memory-profiler --pretty --no-detailed --allocated-strings=0 --retained-strings=0 script.rb
Total allocated: 22.27 MB (206856 objects)
Total retained: 2.98 MB (34152 objects)
```
https://github.com/rubygems/rubygems/commit/2ea2523afd
Co-authored-by: Josh Nichols <josh.nichols@gusto.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On a different patch, it was noticed Ngam Pham that we are calling
`LazySpecification#hash` many times, and simply memoizing that led to a
very considerable performance improvement in his app.
I noticed though that we shouldn't be calling `LazySpecification#hash`
that many times, and I located the culprit at `SpecSet#for` where we
were deduplicating the partial aggregated result on every iteration. It
is enough to do it just once at the end.
This leads on a 12% speedup on Rails repository Gemfile vs the previous
8% I was getting from memoizing `LazySpecification#hash`. Also, after
this patch memoizing `LazySpecification#hash` has no effect in
performance anymore.
https://github.com/rubygems/rubygems/commit/68d00a9edd
Co-authored-by: Ngan Pham <ngan@users.noreply.github.com>
|
|
|
|
| |
https://github.com/ruby/racc/commit/4ecc13c9cb
|
|
|
|
|
|
|
|
|
| |
(https://github.com/ruby/fileutils/pull/69)
Enhanced RDoc for #ln
https://github.com/ruby/fileutils/commit/79fc67f03f
Co-authored-by: Peter Zhu <peter@peterzhu.ca>
|
|
|
|
|
|
|
|
|
|
| |
(https://github.com/ruby/logger/pull/77)
Enhanced RDoc for Logger
https://github.com/ruby/logger/commit/c601ed0370
Co-authored-by: Peter Zhu <peter@peterzhu.ca>
|