| Age | Commit message (Collapse) | Author |
|---|
|
We used `Bundler::RubyVersion.system.gem_version` for a long time, but I
changed this to `Gem.ruby_version` at
https://github.com/rubygems/rubygems/commit/94f96439438e. It's unclear why I did that
though since I believe it was unrelated to the fix in there.
Bootboot patches `Bundler::RubyVersion` to customize how Bundler works
with Ruby versions, and that change broke that.
Since it's unclear to me how to achieve what Bootboot is doing with the
current code, and there was no strong reason for the change, let's
restore it for now.
https://github.com/rubygems/rubygems/commit/8ec36c6017
|
|
compatibility.
Save checksums using = as separator.
https://github.com/rubygems/rubygems/commit/a36ad7d160
|
|
Improve error reporting for checksums, raises a new error class.
Solve for multi-source checksum errors.
Add CHECKSUMS to tool/bundler/(dev|standard|rubocop)26_gems.rb
https://github.com/rubygems/rubygems/commit/26ceee0e76
Co-authored-by: Samuel Giddins <segiddins@segiddins.me>
|
|
https://github.com/rubygems/rubygems/commit/a96a561087
|
|
code.
(https://github.com/rubygems/rubygems/pull/6917)
https://github.com/rubygems/rubygems/commit/2238bdaadc
|
|
This gets the specs passing, and handles the fact that we expect
checkums to be pinned only to a particular source
This also avoids reading in .gem files during lockfile generation,
instead allowing us to query the source for each resolved gem to grab
the checksum
Finally, this opens up a route to having user-stored checksum databases,
similar to how other package managers do this!
Add checksums to dev lockfiles
Handle full name conflicts from different original_platforms when adding checksums to store from compact index
Specs passing on Bundler 3
https://github.com/rubygems/rubygems/commit/86c7084e1c
|
|
if possible
1. Use the checksum provided by the server if provided: provides security
knowing if the gem you downloaded matches the gem on the server
2. Calculate the checksum from the gem on disk: provides security knowing
if the gem has changed between installs
3. In some cases, neither is possible in which case we don't put anything
in the checksum and we maintain functionality as it is today
Add the checksums to specs in the index if we already have them
Prior to checksums, we didn't lose any information when overwriting specs
in the index with stubs. But now when we overwrite EndpointSpecifications
or RemoteSpecifications with more generic specs, we could lose checksum
info. This manually sets checksum info so we keep it in the index.
https://github.com/rubygems/rubygems/commit/de00a4f153
|
|
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
|
|
Closes https://github.com/rubygems/rubygems/issues/7076
Bundler will now use the same (shared) remote fetcher instance that
RubyGems uses.
This will allow installs to use a shared connection pool, which
represents a significant performance improvement on a clean install.
https://github.com/rubygems/rubygems/commit/cd87b40fe1
|
|
See https://github.com/rails/thor/releases/tag/v1.3.0
https://github.com/rubygems/rubygems/commit/3c7165474b
|
|
|
|
|
|
resolve under all locked platforms
https://github.com/rubygems/rubygems/commit/25304f3e8d
|
|
https://github.com/rubygems/rubygems/commit/40989271dd
|
|
https://github.com/rubygems/rubygems/commit/20460bc1ee
|
|
https://github.com/rubygems/rubygems/commit/5f28a68d79
|
|
The `lock` command is specifically designed to manage the lockfile, so
running it should take precedence over any "frozen" setting.
Besides that, "frozen" is not specifically designed as "lockfile cannot
be updated" but as "installation of gems should be prevented if gemfile
is not in sync with the lockfile".
The lock command does not install any gems and preserves the property of
the lockfile being in sycn with its gemfile, so I think frozen should
not influence it.
The current behavior is quite confusing when frozen is set. On an app
where rubocop can get lockfile updates
```
$ bundle lock --update rubocop
Writing lockfile to /path/to/Gemfile.lock
```
Completely silent, it makes you think that it has written the lockfile,
but still no updates.
In verbose mode, it gives a bit more information, but still confusing
and unexpected, and does not change the lockfile:
```
$ bundle lock --update rubocop --verbose
Running `bundle lock --update "rubocop" --verbose` with bundler 2.4.20
Frozen, using resolution from the lockfile
Writing lockfile to /path/to/Gemfile.lock
```
With this commit, it updates the lockfile as expected.
https://github.com/rubygems/rubygems/commit/1d501ae8ea
|
|
https://github.com/rubygems/rubygems/commit/bc233af4d2
|
|
Move the check for unmet dependencies in lockfile just in time to be
able to re-resolve if unmet dependencies are found.
|
|
the ruby platform
https://github.com/rubygems/rubygems/commit/7c50064c3c
|
|
|
|
|
|
|
|
|
|
more than once
https://github.com/rubygems/rubygems/commit/6485adda54
|
|
The formatting was odd, and it hadn't been updated for how the global
source is handled.
https://github.com/rubygems/rubygems/commit/bf19a266ab
|
|
preview
When using a Ruby preview the require path of `bundler/setup` is
similar to `-r/opt/ruby3.3.0-preview2/lib/ruby/3.3.0+0/bundler/setup`.
The special character `+` in the string makes the Regexp fail,
leading to multiple addition of the same require statement each time
`set_rubyopt` is called (e.g. server reloading).
Escaping the characters in the string esure a correct match with all
the different Ruby versions.
https://github.com/rubygems/rubygems/commit/dd43dfa709
|
|
This still allocates a ton (a string for each line, plus a bunch of
splits into arrays), but it helps a bit when Bundler has to go through
dependency resolution.
```
==> memprof.after.txt <==
Total allocated: 194.14 MB (2317172 objects)
Total retained: 60.81 MB (593164 objects)
==> memprof.before.txt <==
Total allocated: 211.97 MB (2404890 objects)
Total retained: 62.85 MB (640342 objects)
```
https://github.com/rubygems/rubygems/commit/c68b41b0e5
|
|
value
`--keep-file-descriptors` is true by default.
https://github.com/rubygems/rubygems/commit/b28e88e228
|
|
As discussed in https://github.com/rubygems/rubygems/issues/6273#issuecomment-1449176658
The `gem` method behaves awkwardly in standalone mode. Assuming bundler
isn't loaded at all, a call to gem might activate a gem that is not part
of the bundle (because it's the gem method defined in
lib/rubygems/core_ext/kernel_gem.rb and not
lib/bundler/rubygems_integration.rb). And when running with
`--disable-gems`, the gem method won't be defined at all so we'll get a
NoMethodError.
Calls to `gem` can appear in dependencies outside an application's
control. To work around this at GitHub we defined our own `Kernel#gem`
that no-ops.
I agree with https://github.com/rubygems/rubygems/issues/6273#issuecomment-1440755882
> people using standalone mode don't want to activate gems like Kernel.gem
This commit redefines `Kernel#gem` in the standalone script to no-op.
https://github.com/rubygems/rubygems/commit/bea17b55f1
|
|
prereleases
https://github.com/rubygems/rubygems/commit/d76dc70d90
|
|
- Specs for GitProxy were incorrect and insufficient
- Specs are now correct and less insufficient
https://github.com/rubygems/rubygems/commit/63d0a8cfd0
|
|
https://github.com/rubygems/rubygems/commit/2851e051c3
|
|
3.3.0-preview2) in Gemfile
https://github.com/rubygems/rubygems/commit/4c1a0511b6
|
|
https://github.com/rubygems/rubygems/commit/042cfb7007
|
|
We have this code that started failing on 3.3.0-dev recently:
```
irb(main):002> require File.join(RbConfig::CONFIG["rubylibdir"], "observer.rb")
/opt/rubies/3.3.0-dev-09-29/lib/ruby/3.3.0+0/bundled_gems.rb:86:in `<': comparison of String with nil failed (ArgumentError)
end + " which #{RUBY_VERSION < SINCE[gem] ? "will be" : "is"} not part of the default gems since Ruby #{SINCE[gem]}"
^^^^^^^^^^
from /opt/rubies/3.3.0-dev-09-29/lib/ruby/3.3.0+0/bundled_gems.rb:86:in `warning?'
from /opt/rubies/3.3.0-dev-09-29/lib/ruby/3.3.0+0/bundled_gems.rb:92:in `block in <module:BUNDLED_GEMS>'
from <internal:/opt/rubies/3.3.0-dev-09-29/lib/ruby/3.3.0+0/rubygems/core_ext/kernel_require.rb>:42:in `block in require'
from <internal:/opt/rubies/3.3.0-dev-09-29/lib/ruby/3.3.0+0/rubygems/core_ext/kernel_require.rb>:39:in `synchronize'
from <internal:/opt/rubies/3.3.0-dev-09-29/lib/ruby/3.3.0+0/rubygems/core_ext/kernel_require.rb>:39:in `require'
from (irb):2:in `<main>'
from <internal:kernel>:187:in `loop'
from /opt/rubies/3.3.0-dev-09-29/lib/ruby/gems/3.3.0+0/gems/irb-1.8.1/exe/irb:9:in `<top (required)>'
from /Users/byroot/.gem/ruby/3.3.0/bin/irb:25:in `load'
from /Users/byroot/.gem/ruby/3.3.0/bin/irb:25:in `<main>'
```
https://github.com/rubygems/rubygems/commit/d67eddb295
|
|
To avoid potential crashes when trying to jump from a drive to another
on Windows, and take the change refactor things a bit.
https://github.com/rubygems/rubygems/commit/7c9a9a431a
|
|
When a path does not make a lot of sense.
https://github.com/rubygems/rubygems/commit/d173c79e9a
|
|
https://github.com/rubygems/rubygems/commit/f0d8255ebd
|
|
https://github.com/rubygems/rubygems/commit/a30712c0fc
|
|
When the latest allowed minor of `dep` adds a new dependency, that new
dependency would be incorrectly resolved to the latest minor of the
first major version.
https://github.com/rubygems/rubygems/commit/fd50c9d4f3
|
|
If a gem is located in a different drive than the Gemfile, standalone
mode will fail to generate the `bundler/setup` script, failing with an
error like
```
ArgumentError: different prefix: "C:/" and "D:/a/rubygems/rubygems/bundler/tmp/2/bundled_app/bundle/bundler"
C:/hostedtoolcache/windows/Ruby/3.0.5/x64/lib/ruby/3.0.0/pathname.rb:528:in `relative_path_from'
D:/a/rubygems/rubygems/bundler/tmp/2/gems/system/gems/bundler-2.4.20/lib/bundler/installer/standalone.rb:58:in `gem_path'
D:/a/rubygems/rubygems/bundler/tmp/2/gems/system/gems/bundler-2.4.20/lib/bundler/installer/standalone.rb:33:in `block (2 levels) in paths'
D:/a/rubygems/rubygems/bundler/tmp/2/gems/system/gems/bundler-2.4.20/lib/bundler/installer/standalone.rb:32:in `map'
D:/a/rubygems/rubygems/bundler/tmp/2/gems/system/gems/bundler-2.4.20/lib/bundler/installer/standalone.rb:32:in `block in paths'
```
I'm fixing this by falling back to using a full path in this case.
This was caught by a failing spec, so I'm not adding new specs.
https://github.com/rubygems/rubygems/commit/3cb9b9ab7a
|
|
```
==> memprof.after.txt <==
Total allocated: 673.08 kB (7644 objects)
Total retained: 107.35 kB (1018 objects)
==> memprof.before.txt <==
Total allocated: 739.12 kB (9140 objects)
Total retained: 138.61 kB (1695 objects)
```
Savings will scale by the number of lines in the lockfile
https://github.com/rubygems/rubygems/commit/f6abf4439c
|
|
Preferring instead to spawn the subprocess in the correct directory
https://github.com/rubygems/rubygems/commit/ad5abd6a45
|
|
We were setting the wrong `extension_dir` for git specs stubs
Additionally, the call to `self.extension_dir` was loading the
remote spec, which was avoidable since the stub had an extension dir
(and in fact its #gem_build_complete_path does exactly what we want
anyway)
Finally, now set the base_dir when loading the remote_spec from a
stub specification, since the git source sets the base dir for stubs
based on where the spec _will_ be installed to, and we want to preserve
that so the base_dir for the loaded spec & the stub are the same
https://github.com/rubygems/rubygems/commit/a94acb465b
|
|
https://github.com/rubygems/rubygems/commit/63b422b71a
|
|
Avoids constructing several strings
https://github.com/rubygems/rubygems/commit/8a322dbe11
|
|
https://github.com/rubygems/rubygems/commit/5ed4c600da
|
|
Remove the default nested hash in Index entirely
Index#search_all now yields or returns enum since that's what caller
needs.
https://github.com/rubygems/rubygems/commit/c45ea3bbe2
|
|
Since the hashes have a default proc that returns a (new) empty hash, we
can avoid allocating those empty hashes when we are only doing lookups.
Test from running `bundle update --bundler` against a rails app I have
lying around:
```
==> memprof.after.txt <==
Total allocated: 9.71 MB (68282 objects)
Total retained: 4.87 MB (33791 objects)
==> memprof.before.txt <==
Total allocated: 10.83 MB (100596 objects)
Total retained: 5.02 MB (34721 objects)
```
https://github.com/rubygems/rubygems/commit/8f7c9cb23e
|
