| Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
* Merge RubyGems-3.5.12 and Bundler-2.5.12
* Merge RubyGems-3.5.13 and Bundler-2.5.13
* Merge RubyGems-3.5.14 and Bundler-2.5.14
* Merge RubyGems-3.5.15 and Bundler-2.5.15
* Merge RubyGems-3.5.16 and Bundler-2.5.16
|
|
Co-authored-by: Nobuyoshi Nakada <nobu@ruby-lang.org>
|
|
* Merge RubyGems-3.5.4 and Bundler-2.5.4
* Merge RubyGems-3.5.5 and Bundler-2.5.5
* Make tests play with upstream Ruby tests
CI broke in https://github.com/ruby/ruby/pull/9604 because if any Ruby
tests run `require 'net/http'`, they will pollute the
`$LOADED_FEATURES` for the RubyGems tests. We can fix this by renaming
the test default gem from `net-http` to `my-http`.
See https://github.com/rubygems/rubygems/pull/7379#issuecomment-1901241299
for more details.
---------
Co-authored-by: Stan Hu <stanhu@gmail.com>
|
|
|
|
rubygems-generate_index gem
So generate_index can be implemented with dependencies, such as the compact index
Took this approach from feedback in https://github.com/rubygems/rubygems/pull/6853
Running `gem generate_index` by default will use an installed rubygems-generate_index, or install and then use the command from the gem
Apply suggestions from code review
https://github.com/rubygems/rubygems/commit/fc1cb9bc9e
Co-authored-by: Hiroshi SHIBATA <hsbt@ruby-lang.org>
|
|
https://github.com/rubygems/rubygems/commit/bb66253f2c
|
|
Looks for the CHECKSUMS section in the lockfile, activating the feature
only if the section exists. Without a CHECKSUMS section, Bundler will
continue as normal, validating checksums when gems are installed while
checksums from the compact index are present.
https://github.com/rubygems/rubygems/commit/2353cc93a4
|
|
gemspec
https://github.com/rubygems/rubygems/commit/e78c0a4a48
|
|
https://github.com/rubygems/rubygems/commit/9ab1136036
|
|
If a Gemfile duplicates a development dependency also defined in a local
gemspec with a different requirement, the requirement in the local
gemspec will be silently ignored.
This surprised me.
I think we should either:
* Make sure both requirements are considered, like it happens for
runtime dependencies (I added a spec to illustrate the current behavior
here).
* Add a warning that the requirement in the gemspec will be ignored.
I think the former is slightly preferable, but it may cause some
bundle's that previously resolve to no longer resolver.
I went with the latter but the more I think about it, the more this
seems like it should behave like the former.
https://github.com/rubygems/rubygems/commit/ad6843972f
|
|
https://github.com/rubygems/rubygems/commit/e41156e272
|
|
writable bit
Instead, don't check that at all and proceed. If something fails to be
written inside GEM_HOME, we'll eventually fail with a proper permissions
error.
In addition to that, the writable bit in GEM_HOME is not even reliable,
because only the immediate parent is actually checked when writing. For
example,
```
$ mkdir -p foo/bar
$ chmod -w foo
$ touch foo/bar/baz # writes without issue
```
https://github.com/rubygems/rubygems/commit/4bced7ac73
|
|
code.
(https://github.com/rubygems/rubygems/pull/6917)
https://github.com/rubygems/rubygems/commit/2238bdaadc
|
|
We lock the checksum for each resolved spec under a new CHECKSUMS
section in the lockfile.
If the locked spec does not resolve for the local platform, we preserve
the locked checksum, similar to how we preserve specs.
Checksum locking only makes sense on install. The compact index
information is only available then.
https://github.com/rubygems/rubygems/commit/bde37ca6bf
|
|
Move the check for unmet dependencies in lockfile just in time to be
able to re-resolve if unmet dependencies are found.
|
|
https://github.com/rubygems/rubygems/commit/0f58ef6a32
|
|
Let it deal with legacy gems with equivalent version and different
dependencies.
https://github.com/rubygems/rubygems/commit/b430babe97
|
|
platforms
https://github.com/rubygems/rubygems/commit/f3c49ad3f7
|
|
https://github.com/rubygems/rubygems/commit/446cc57a7ccdf1924deb291be9571219e7ba8523
Notes:
Merged: https://github.com/ruby/ruby/pull/6198
|
|
Instead of showing the bug report template.
https://github.com/rubygems/rubygems/commit/0c8b6f7dd5
|
|
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
|
|
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
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/5669
|
|
is missing
When I run bundle install with BUNDLE_DEPLOYMENT=true in the environment
on a different platform than I usually do development, I get the
following output to the console (wrapped exactly as shown):
Your bundle only supports platforms ["x86_64-darwin-19"] but your local platform
is x86_64-linux. Add the current platform to the lockfile with `bundle lock
--add-platform x86_64-linux` and try again.
Because the way the message wraps, its not as simple as copying the
suggested command to the clipboard because it contains a newline:
$ bundle lock
Writing lockfile to [...]/Gemfile.lock
$ --add-platform x86_64-linux
Adding a newline right before the command forces the command in the
error message to be on the same line, which facilitates copy-pasting the
command in the message.
https://github.com/rubygems/rubygems/commit/4cf6989b11
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/5350
|
|
These specs were monkeypatching `RUBY_VERSION`, but that obviously
doesn't change the running ruby to behave any different.
The removal of some features, in particular, `String#untaint`, made
these specs fail, because untaint is no longer available under ruby-core
and bundler calls `untaint` when `RUBY_VERSION` is less than "2.7",
which these specs were overwriting it to be.
Rewrite these specs to not overwrite `RUBY_VERSION`, but still test the
same things.
https://github.com/rubygems/rubygems/commit/e8c7b92901
Notes:
Merged: https://github.com/ruby/ruby/pull/5350
|
|
We stay to the stable version for releasing Ruby 3.1.0.
Revert commits:
b86a7ba49252e00e19c22bbcdc821b5acc31ff92
ef973aa7aa65143a4f05d623c016d459426770d0
|
|
different platforms
https://github.com/rubygems/rubygems/commit/83bc87ca98
|
|
https://github.com/rubygems/rubygems/commit/04b1ac72b9
|
|
It doesn't add anything.
https://github.com/rubygems/rubygems/commit/ece3c864df
|
|
can't be deleted
Instead of showing the bug report template with an error at a random
place.
https://github.com/rubygems/rubygems/commit/882ad3ab57
|
|
Instead of showing the bug report place with an error at a randome
place.
https://github.com/rubygems/rubygems/commit/241854ce73
|
|
incomplete resolve
In case we have a corrupted lockfile that claims to support a platform, but
it's missing platform specific gems for it, bundler has a check that
detects the situation and forces a re-resolve. The result of this check
is kept under the `@locked_specs_incomplete_for_platformn` instance
variable in `Definition`.
The installer, however, calls `Definition#nothing_changed?` before this
instance variable has been filled, so the result of it is actually
incorrect here since it will claim that nothing has changed, but
something has changed (locked specs are incomplete for the current
platform).
The consequence of this incorrect result is that the installer thinks it
can go on without re-resolving, resulting in the incomplete resolution
from the lockfile being used, and in a crash being triggered due to
that.
The solution is to make sure the `@locked_specs_incomplete_for_platform`
instance variable is filled before `nothing_changed?` gets called.
Moving it to `initialize` makes the most sense, not because it's the
best place for it (we can refactor this later), but because all of the
other "outdated definition" checks are already set there.
https://github.com/rubygems/rubygems/commit/708afdd789
|
|
https://github.com/rubygems/rubygems/commit/8950631f02
|
|
between sentence breaks
https://github.com/rubygems/rubygems/commit/5cdda53382
Notes:
Merged: https://github.com/ruby/ruby/pull/4789
|
|
network
If the cache was missing, `bundler` would try to re-fetch it. With the
`--local` flag, it should just look at installed gems.
https://github.com/rubygems/rubygems/commit/630d29c69e
Notes:
Merged: https://github.com/ruby/ruby/pull/4789
|
|
Bundler has deprecated gemfiles without a global source and this feature
is now obsolete. `Bundler::Definition#has_rubygems_remotes?` is removed
because it's not used anymore.
https://github.com/rubygems/rubygems/commit/d29dd2cb7b
|
|
This is in preparation for deprecating source-less gemfiles.
https://github.com/rubygems/rubygems/commit/d6493fa3e2
|
|
The is the previous intentional behaviour until
https://github.com/rubygems/bundler/commit/ca0676cb1c638e0b9747ea8c18f28adf82cc01de.
In my opinion, that previous behaviour was better and should be
restored, because we want our users to always see warnings and fix them.
And the original issue that motivated the change is fixable by other
means, namely through `BUNDLE_SILENCE_ROOT_WARNING`, or through
`BUNDLE_SILENCE_DEPRECATIONS` in general. Finally, the --quiet option is
still documented as "only print errors and warnings".
So this PR essentially reverts
https://github.com/rubygems/bundler/commit/ca0676cb1c638e0b9747ea8c18f28adf82cc01de
for the above reasons.
https://github.com/rubygems/rubygems/commit/35f2254dfc
|
|
We'll be removing the warning about no gem sources, so this spec will no
longer test that warnings are hidden by `--quiet`.
Test that in another way so that we don't lose the coverage when we
drop the specific warning about no gem server sources.
https://github.com/rubygems/rubygems/commit/cce4f86d28
|
|
A fresh `gem install` might not reproduce the exact `bundle install`
environment that originally caused the error. It also makes it harder
for the user to troubleshoot the error since she needs to run a separate
command.
Instead, show the original error and backtrace directly.
https://github.com/rubygems/rubygems/commit/49c2abfec6
|
|
When a development dependency was duplicated inside the gemspec and
Gemfile with the same requirements, we went from printing a warning to
removing the gem altogether.
This change makes it not print a warning, but don't remove the gem
either.
https://github.com/rubygems/rubygems/commit/8bb2488131
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/4648
|
|
55634a8af18a52df86c4275d70fa1179118bcc20
Notes:
Merged: https://github.com/ruby/ruby/pull/4021
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/3982
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/3864
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/3659
|