This was introduced by 0b7be7bb77, because
the original patch was not adapted to some recent refactorings.
0bca60d6e5
Co-authored-by: Hiroshi SHIBATA <hsbt@ruby-lang.org>
I suspect someone could be setting this instance variable, and the
previous changes made that no longer effective.
Also I implemented a previous TOOD in `full_gem_path` the other way
around:
> # TODO: This is a heavily used method by gems, so we'll need
> # to aleast just alias it to #gem_dir rather than remove it.
I made `gem_dir` an alias of `full_gem_path` rather than the opposite.
This alternative change keeps both methods symmetric without deprecating
either of them for now.
28983973a3
See https://github.com/rubygems/rubygems/issues/8046 for details
Prior to this commit a cached git source without a specific ref wouldn't
survive pushing to a remote and then pulling on a different machine.
We'd end up without a refs directory in the cache, at which point git
won't recognize it as a repo.
This commit fixes the problem by adding a refs directory if it's not
already there. This needs to be done as early as possible, so any git
commands will work as expected, so this commit adds it before creating
the app cached git proxy.
8c89f0b065
By the time `cached_gem` is called, default gem cache has already been
handled. So no need to try redownload it again, it's enough to check the
cache location directly.
70e10236b6
of irb_break irb_catch and irb_next command
(https://github.com/ruby/irb/pull/1004)
* Remove KEYWORD_ALIASES which handled special alias name of irb_break irb_catch and irb_next command
* Remove unused instance variable user_aliases
Co-authored-by: Stan Lo <stan001212@gmail.com>
---------
f256d7899f
Co-authored-by: Stan Lo <stan001212@gmail.com>
In a `bundle exec` context, the local specification will actually be
part of the known specifications, so RubyGems will assume it has already
been installed, which is not actually true.
This will cause `RequestSet` to rebuild extensions for a gem that's not
actually installed, causing errors.
The fix is to make sure detection of installed activation requests
considers not only that there's a known spec with the same full name as
the one being installed, but also that this spec is installed in the
same gem_home were pretend to install the new gem.
a8ef1286a6
DSLError prints the specific line in a Gemfile where the error was
raised. That's helpful when the error was explicitly raised by the
Gemfile DSL or, in the case it's implicitly raised, when the offending
code lives right in the Gemfile.
If it's an internal error, or something buried dowm in user code called
from the Gemfile, `DSLError` is not helpful since it hides the actual
culprit.
This commit tries to only raise `DSLError` in the cases mentioned above
and otherwise let the original error be raised.
b30ff5a682
Currently, an exe file isn't executable when generating new gems
because it doesn't have the correct permission.
This PR sets the correct permission same as files under the `bin`.
6509bf128a