Age | Commit message (Collapse) | Author |
|
Sometimes you want this, sometimes you don't. And when you don't, this
hides other debugging puts you may have added.
https://github.com/rubygems/rubygems/commit/df37582c81
|
|
This is mainly to align this test case with the
`test_process_options_does_not_fallback_to_user_install_when_gem_home_
not_writable_and_no_user_install`, where the `install_dir` is checked
already.
https://github.com/rubygems/rubygems/commit/02b1884b61
|
|
installation
The `options[:user_install]` might have three states:
* `true`: `--user-install`
* `false`: `--no-user-install` and
* `nil`: option was not specified
However, this had not been respected previously and the `false` and `nil`
were treated the same. This could lead to auto user installation despite
`--no-user-install` being specified on the command line.
Fixes https://github.com/rubygems/rubygems/pull/7237
https://github.com/rubygems/rubygems/commit/9281545474
|
|
https://github.com/rubygems/rubygems/commit/bb66253f2c
|
|
https://github.com/rubygems/rubygems/commit/6a06b0763f
|
|
when GEM_HOME not writable
https://github.com/rubygems/rubygems/commit/f67bced16b
|
|
https://github.com/rubygems/rubygems/commit/6539da07aa
|
|
The main purpose is to put handling of user installation into the same
place as e.g. handling the --build-root option handling. There is no
reason why the --build-root option should not prefix also paths used for
user installation.
Please note that the `util_installer` in
`test_generate_plugins_with_user_install` enforced the `:install_dir`,
which is against what user install is about.
https://github.com/rubygems/rubygems/commit/0b10cb41aa
|
|
https://github.com/rubygems/rubygems/commit/6d445a85d7
|
|
https://github.com/rubygems/rubygems/commit/225fdf0b2e
|
|
We can install RubyGems plugin by "gem install XXX". The installed
plugin is used from the NEXT "gem ...".
For example, "gem install gem-src kaminari" doesn't use gem-src plugin
for kaminari. "gem install gem-src && gem install kaminari" uses
gem-src plugin for kaminari.
How about loading a plugin immediately when the plugin is installed?
If this proposal is implemented, "gem install gem-src kaminari" works
like "gem install gem-src && gem install kaminari".
https://github.com/rubygems/rubygems/commit/4917d96f4c
|
|
https://github.com/rubygems/rubygems/commit/4eaac27107
|
|
|
|
https://github.com/rubygems/rubygems/commit/132a56569d
|
|
https://github.com/rubygems/rubygems/commit/67ece7b8b6
|
|
https://github.com/rubygems/rubygems/commit/9264d83421
|
|
https://github.com/rubygems/rubygems/commit/b18a4ef076
|
|
https://github.com/rubygems/rubygems/commit/1d52eff8bf
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/7582
|
|
https://github.com/rubygems/rubygems/commit/be853dfe3b
Notes:
Merged: https://github.com/ruby/ruby/pull/7582
|
|
https://github.com/rubygems/rubygems/commit/80b57da926
|
|
https://github.com/rubygems/rubygems/commit/c766a65885
|
|
https://github.com/rubygems/rubygems/commit/4e77a1d1d5
|
|
https://github.com/rubygems/rubygems/commit/5c88c77873
|
|
https://github.com/rubygems/rubygems/commit/cb554f6eb7
|
|
Layout/EmptyLinesAroundExceptionHandlingKeywords
https://github.com/rubygems/rubygems/commit/ad1fe68d97
|
|
https://github.com/rubygems/rubygems/commit/4d680320e3
|
|
https://github.com/rubygems/rubygems/commit/00117e69cc
|
|
https://github.com/rubygems/rubygems/commit/d8efd919db
|
|
https://github.com/rubygems/rubygems/commit/7c096a5df8
|
|
extensions
https://github.com/rubygems/rubygems/commit/98b6a959bd
Notes:
Merged: https://github.com/ruby/ruby/pull/6966
|
|
Some tests check that the shared objects are actually installed, but
checking an intermediate build file instead of the installed one.
https://github.com/rubygems/rubygems/commit/ad526073b0
Notes:
Merged: https://github.com/ruby/ruby/pull/6966
|
|
Add test for not leaving empty files if ENOSPC is raised during 'gem install'
https://github.com/rubygems/rubygems/commit/8e0e20f079
|
|
Pick from https://github.com/rubygems/rubygems/commit/dfbb5a38114640e0d8d616861607f3de73ee0199
Notes:
Merged: https://github.com/ruby/ruby/pull/6224
|
|
https://github.com/rubygems/rubygems/commit/425b78637f
|
|
Pick from https://github.com/rubygems/rubygems/commit/8331e63263081a6aa690d8025d2957f30c4e814a
Notes:
Merged: https://github.com/ruby/ruby/pull/6209
|
|
Signed-off-by: Takuya Noguchi <takninnovationresearch@gmail.com>
|
|
`FileUtils`
We were trying to remove directories using `FileUtils.rm_f` which is
unexpected and does not remove anything. Changing to `FileUtils.rm_rf`
actually removes the directories properly. That itself showed other
issues:
* One test was actually removing the gem package it was about to
install, since it was living in the cache folder. To fix that, avoid
removing the cache folder, and only make sure the other directories
are created automatically, which seems enough.
* Another test was actually removing an incorrect directory. Change it
to remove the right one (the one that's asserted later to have been
created).
https://github.com/rubygems/rubygems/commit/5538e7ff20
|
|
https://github.com/rubygems/rubygems/commit/32a5e9057a
|
|
https://github.com/rubygems/rubygems/commit/386b3b85ca
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/5334
|
|
concurrently
When bundler parallel installer installs gems concurrently, one can get
confusing warnings like the following:
```
"[/home/runner/work/rubygems/rubygems/bundler/tmp/2/gems/system/specifications/zeitwerk-2.4.2.gemspec] isn't a Gem::Specification (NilClass instead).
```
I've got these warnings several times in the past, but I never managed
to reproduce them, and never look deeply into the root cause, but this
time a got a cause that reproduced quite frequently, so I looked into
it.
The problem is one thread reading a gemspec while another thread is
writing it. The write of the gemspec was not protected, so
`Gem::Specification.load` could end up seeing a truncated gemspec and
thus throw this warning.
The fix involve two changes:
* Change the methods that write gemspecs to use `Gem.binary_write` which
is protected by a lock.
* Fix `Gem.binary_write` to create the file lock at file creation time,
not when the file already exists after.
The realworld user problem caused by this issue happens in bundler, but
I'm fixing it in rubygems first, and then I'll backport to bundler
whatever needs backporting to fix the issue on the bundler side.
https://github.com/rubygems/rubygems/commit/a672e7555c
|
|
This reverts commit af604436d8141c34cb2e1e645b9b0d47bfd55a55.
The issue that led to introducing it was never reproduced. I tried to
repro with this patch and it still works just fine. Since this removal
is getting in the middle for some race conditions I'm facing, I'm
reverting the patch.
https://github.com/rubygems/rubygems/commit/2dd267f0e4
|
|
The current `setup_base_installer` ends up using the `quick_gem` helper,
which leaves the created specification installed. Instead, make sure to
use the `util_spec` helper, which does a similar thing but doesn't leave
the specification installed.
The idea is that tests do not rely on the installer removing existing
gemspecs, bacause I plan to stop doing that.
https://github.com/rubygems/rubygems/commit/843f1a0abc
|
|
The previous behavior was to automatically require `bundler/setup`
everytime `rubygems` was required, which I think was too much.
https://github.com/rubygems/rubygems/commit/b25379a295
Notes:
Merged: https://github.com/ruby/ruby/pull/4789
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/4533
|
|
|
|
This variable had a typo (it's `@gemhome`), but the test is still
passing, so I assume it's not needed.
https://github.com/rubygems/rubygems/commit/3b88642bdb
|
|
https://github.com/rubygems/rubygems/commit/c77868a555
|
|
Because pend of test-unit raises exception.
https://github.com/rubygems/rubygems/commit/b5e2d0855a
Notes:
Merged: https://github.com/ruby/ruby/pull/4491
|