| 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.6 and Bundler-2.5.6
* Merge RubyGems-3.5.7 and Bundler-2.5.7
* Merge RubyGems-3.5.8 and Bundler-2.5.8
* Partly reverted about https://github.com/rubygems/rubygems/pull/7483
* Merge RubyGems-3.5.9 and Bundler-2.5.9
|
|
|
|
https://github.com/rubygems/rubygems/commit/f6258e5679
Co-authored-by: AndrewSwerlick <andrew.swerlick@gmail.com>
|
|
And make it easier to update next time.
https://github.com/rubygems/rubygems/commit/1ea4bfa5d8
|
|
install
https://github.com/rubygems/rubygems/commit/6847709ee0
|
|
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
|
|
https://github.com/rubygems/rubygems/commit/ed4eaefac0
|
|
If a platform specific variant would not match the current Ruby, we would still be
considering it compatible with the initial resolution and adding its
platform to the lockfile, but we would later fail to materialize it for
installation due to not really being compatible.
Fix is to only add platforms for variants that are also compatible with
current Ruby and RubyGems versions.
https://github.com/rubygems/rubygems/commit/75d1290843
|
|
https://github.com/rubygems/rubygems/commit/4ce66c41a2
|
|
https://github.com/rubygems/rubygems/commit/93619c97ff
|
|
Since we started locking the specific platform in the lockfile, that has
created an annoying situation for users that don't develop on Linux.
They will create a lockfile on their machines, locking their local
platform, for example, darwin. But then that lockfile won't work
automatically when deploying to Heroku for example, because the lockfile
is frozen and the Linux platform is not included.
There's the chance though that resolving against two platforms (Linux +
the local platform) won't succeed while resolving for just the current
platform will. So, instead, we check other platform specific variants
available for the resolution we initially found, and lock those
platforms and specs too if they satisfy the resolution.
This is only done when generating new lockfiles from scratch, existing
lockfiles should keep working as before, and it's only done for "ruby
platforms", i.e., not Java or Windows which have their own complexities,
and so are excluded.
With this change, we expect that MacOS users can bundle locally and
deploy to Heroku without needing to do anything special.
https://github.com/rubygems/rubygems/commit/5f24f06bc5
|
|
https://github.com/rubygems/rubygems/commit/7ab4c203f9
|
|
https://github.com/rubygems/rubygems/commit/3e7f1379fb
|
|
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>
|
|
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
|
|
https://github.com/rubygems/rubygems/commit/40989271dd
|
|
the ruby platform
https://github.com/rubygems/rubygems/commit/7c50064c3c
|
|
https://github.com/rubygems/rubygems/commit/2851e051c3
|
|
remote gemfiles
If a legacy multi remote Gemfile depends transitively on a default gem,
then in standalone mode we'd fail to fetch the proper version from the
source that includes it, since we were adding it to `specs` (instead of
`remote_specs`), which was already including the default version of the
gem, and thus preventing the remote version from "overwriting that" and
being added to the index. We should add it to the `remote_specs` index
directly instead.
https://github.com/rubygems/rubygems/commit/05f4f9dfc0
|
|
On legacy Gemfiles with multiple remote sources, where all of them
support the compact index API, we were still falling back to full
indexes.
Fixing this also allows to simplifying the code.
https://github.com/rubygems/rubygems/commit/b1357c8e72
|
|
https://github.com/rubygems/rubygems/commit/258476c38a
|
|
git sources
Previously, when sorting and comparing git Gemfile vs lockfile sources during
`bundler/setup` to figure out whether we need to re-resolve or not, we
would try to find the default branch if nothing more specific was
specified in the Gemfile.
If the git cache has been deleted thought, that would fail.
The error would still be swallowed (and the branch would simply not be
displayed), but trying to clone would still generate the side effect of
creating the parent folder for the clone.
That could affect non-writable systems that don't expect `bundler/setup`
to write to the filesystem at all.
To fix this, override `Bundler::Source::Git#identifier` to use
exclusively static information, so it does not even try to clone the
repo nor generate any side effects.
https://github.com/rubygems/rubygems/commit/582eb2ef39
|
|
lockfile
When dependencies in path sources have changed, we'll be re-resolving,
and we can't really know whether the resolution will be valid or invalid
for the Ruby platform, so skip the removal in that case.
https://github.com/rubygems/rubygems/commit/afc3b0956f
|
|
Pick from https://github.com/rubygems/rubygems/commit/880dd95996c93adc1e032399816931b243c5fe17
Notes:
Merged: https://github.com/ruby/ruby/pull/7961
|
|
This error message is also printed when using `bundler/setup` in frozen
model, so we're not necessarily installing any gems when it happens.
This new message play nicer with all situations.
https://github.com/rubygems/rubygems/commit/6874bbacce
|
|
I think it communicates better what's going on.
https://github.com/rubygems/rubygems/commit/07a25767a4
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/7873
|
|
When dependencies have changed, we'll be re-resolving, and we can't
really know whether the resolution will be valid or invalid for the Ruby
platform, so skip the removal in that case.
The fix worked, but made some other specs fail, and surfaced that the
`@dependencies_changed` attribute was actually being incorrect set when
explicitly unlocking. Fixed that with an early return.
https://github.com/rubygems/rubygems/commit/20d8f5e5d9
|
|
https://github.com/rubygems/rubygems/commit/86b574824d
|
|
To make it easier to change the default platforms that get locked later.
https://github.com/rubygems/rubygems/commit/255c4012ec
|
|
Nicer :)
https://github.com/rubygems/rubygems/commit/c0ab2893c3
|
|
https://github.com/rubygems/rubygems/commit/3139587be9
|
|
to #windows?. (This is done instead of logging a deprecation warning.)
https://github.com/rubygems/rubygems/commit/b9fcc7c0ab
|
|
https://github.com/rubygems/rubygems/commit/cb4fc41cbc
Notes:
Merged: https://github.com/ruby/ruby/pull/7345
|
|
* Replaces the wording of "is forbidden" with "cannot be used"
* Fixes the method signature of VersionRange::Empty#eql?
https://github.com/rubygems/rubygems/commit/8c6b3f130b
Co-authored-by: Daniel Colson <danieljamescolson@gmail.com>
Notes:
Merged: https://github.com/ruby/ruby/pull/7345
|
|
Pick from https://github.com/rubygems/rubygems/commit/5ace20dbecfeaf09fba5f616193f3cfcff70ba00
Notes:
Merged: https://github.com/ruby/ruby/pull/7203
|
|
Given an existing application using native gems (e.g., nokogiri)
And a lockfile generated with a stable ruby version
When we test the application against ruby-head and `bundle install`
Then bundler should fall back to the generic ruby platform gem
Note that this test has been passing since 45931ac9
https://github.com/rubygems/rubygems/commit/0ecc6de378
Notes:
Merged: https://github.com/ruby/ruby/pull/7203
|
|
from https://github.com/rubygems/rubygems/commit/0635c1423db5d7c461d53bf0c3329bca75de7609
Notes:
Merged: https://github.com/ruby/ruby/pull/7094
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/7020
|