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.
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").
6e66ee4235
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.
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.
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.
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.
5d154dd50e
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
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.
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.
174cb66863
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.
5fa3e6f04a
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. :)
fd4bdb35e2
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.
8f104228d3
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.
68d00a9edd
Co-authored-by: Ngan Pham <ngan@users.noreply.github.com>
