| Age | Commit message (Collapse) | Author |
|---|
|
x64-mingw-ucrt (platforms)
- the x64-mingw32 platform has been superseded by x64-mingw-ucrt
- the mingw-ucrt platform is present as of Windows 10, which was released 10 years ago in 2015 and all versions prior to 10 are end-of-life and 10 will be by mid October 2025
- newer rubies use the mingw-ucrt platform instead of the mingw32 platform, meaning using the deprecated platform can cause issues during gem installation
https://github.com/rubygems/rubygems/commit/b9d871022e
|
|
have changed
Since we will now add it back if the final resolution is compatible, we
can also get this kind of edge case (`bundle add`) working.
https://github.com/rubygems/rubygems/commit/cdc5ebec77
|
|
https://github.com/rubygems/rubygems/commit/e891be9197
Notes:
Merged: https://github.com/ruby/ruby/pull/12968
|
|
https://github.com/rubygems/rubygems/commit/aee52d2874
Co-authored-by: johnnyshields <[email protected]>
|
|
https://github.com/rubygems/rubygems/commit/96496e3f53
Co-authored-by: Johnny Shields <[email protected]>
|
|
I think they add unnecessary indirection and inconsistency to the specs.
https://github.com/rubygems/rubygems/commit/609924d985
|
|
https://github.com/rubygems/rubygems/commit/d24c0c20e3
|
|
lockfile unless necessary
Even if they don't match the current Ruby version, they could still work
in other rubies. So it's better to keep them.
https://github.com/rubygems/rubygems/commit/9a3e583b0c
Notes:
Merged: https://github.com/ruby/ruby/pull/12568
|
|
https://github.com/rubygems/rubygems/commit/bc2537de71
|
|
https://github.com/rubygems/rubygems/commit/f68a2c30bb
|
|
platform
Using an old bundler version was necessary at the beginning because we
checked the version of Bundler being run in order to enable the new
behavior. But we removed that a long time ago and now we only look at
whether the lockfile only includes "ruby" as a platform or not.
https://github.com/rubygems/rubygems/commit/8fc3d38ff3
|
|
https://github.com/rubygems/rubygems/commit/99b4ac4548
|
|
"ruby" platform
https://github.com/rubygems/rubygems/commit/4168a7f488
|
|
And get specs passing.
https://github.com/rubygems/rubygems/commit/c23b5f5b84
|
|
Use the standard sources to avoid having to explictly pass ENV with the repo.
https://github.com/rubygems/rubygems/commit/95055dba57
|
|
I failed to ignore (again) specs only considered for resolution under
some platforms that are not the current one.
https://github.com/rubygems/rubygems/commit/b72deec57e
|
|
All that we expect here is no changes.
https://github.com/rubygems/rubygems/commit/ff984b6133
|
|
when locked for a specific platform
If they are already in the lockfile as the most specific variant for a
platform, we shouldn't change that unless explicitly unlocking.
https://github.com/rubygems/rubygems/commit/a901660498
|
|
While working on something else I noticed:
* Usage of uppercased "RUBY" and "JAVA" as platforms, when those don't
really exist.
* Usage of some test gems with "1.0" as gemspec version and "1.0.0" as
actual version.
This commit fixes both inconsistencies to make things more expectable.
https://github.com/rubygems/rubygems/commit/e3ec32e247
|
|
add_runtime_dependency
https://github.com/rubygems/rubygems/commit/9a08043858
|
|
|
|
When locked only to RUBY, and some locked spec does not meet locked
dependencies, Bundler would remove the only locked platform and end up
creating a lockfile with empty sections.
We can't rely on our criteria to remove invalid platforms if locked
specs are not valid in the first place.
https://github.com/rubygems/rubygems/commit/1dba05cf53
|
|
local platform is locked
https://github.com/rubygems/rubygems/commit/36a02c6128
|
|
If RUBY is the only platform in the lockfile, we were skipping adding
the local platform to the list of resolution platforms. This generally
works anyways, because we had some code to still add it if the RUBY
platform is not valid for the set of locked gems.
However, sometimes it can happen that "RUBY" is valid for the current
set of locked gems, but when adding a new dependency, it becomes
invalid. For example, when adding sorbet to a Gemfile, that will
introduce `sorbet-static` as an indirect dependency which does not have
a generic "RUBY" variant. This will cause resolution to take a long time
continuously backtracking trying to find solutions that don't introduce
`sorbet-static` as a dependency and will eventually fail.
Instead, we can always add the local platform to the set of resolution
platforms before resolving, and remove it as necessary after resolution
so that we lock the correct set of platforms.
https://github.com/rubygems/rubygems/commit/6ed1fe6050
|
|
were not used
https://github.com/rubygems/rubygems/commit/5ce9a7ff17
|
|
musl vs gnu case
This case is for not locking things like `arm-darwin-23` when the
lockfile already includes `arm-darwin`, so that we don't infinitely keep
redundant versioned platforms in the lockfile when not necessary.
We detect this with `Gem::Platform#===`. For example,
`Gem::Platform.new("arm-darwin-23") === Gem::Platform.new("arm-darwin")`
but they're not `==`.
However, in the case of `-musl` vs `-gnu`, those act as the platform
"version", but `===` is not commutative for them. This is explained in
`===` docs.
We only want to exclude the local platform in situations when
`Gem::Platform#===` is actually commutative.
https://github.com/rubygems/rubygems/commit/8099c4face
|
|
https://github.com/rubygems/rubygems/commit/146de56353
|
|
https://github.com/rubygems/rubygems/commit/235f7b4266
|
|
|
|
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
|
|
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
|
|
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
|
|
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 <[email protected]>
|
|
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
|
|
Pick from https://github.com/rubygems/rubygems/commit/880dd95996c93adc1e032399816931b243c5fe17
Notes:
Merged: https://github.com/ruby/ruby/pull/7961
|
|
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
|
|
To make it easier to change the default platforms that get locked later.
https://github.com/rubygems/rubygems/commit/255c4012ec
|
|
* 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 <[email protected]>
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
|
|
Pick from https://github.com/rubygems/rubygems/commit/823c776d951f3c35094611473ec77f94e8bf6610
Notes:
Merged: https://github.com/ruby/ruby/pull/6890
|
|
https://github.com/rubygems/rubygems/pull/5960
Co-authored-by: David Rodríguez <[email protected]>
|
