| Age | Commit message (Collapse) | Author |
|
|
|
https://github.com/rubygems/rubygems/commit/b0983f392f
|
|
This will help centralize wheel platform selection logic eventually
Signed-off-by: Samuel Giddins <segiddins@segiddins.me>
|
|
https://github.com/rubygems/rubygems/commit/ed31e888fd
|
|
https://github.com/rubygems/rubygems/commit/42534e746b
|
|
If we materialized to a different platform, then the dependencies may
actually be different so the validation does not really make sense.
https://github.com/rubygems/rubygems/commit/68fad98e6f
|
|
https://github.com/rubygems/rubygems/commit/4b6f07f634
|
|
In frozen mode, the previous logic would not set the platform locked
originally in the materialized specification, and that would trigger the
warning about insecure materialization incorrectly.
https://github.com/rubygems/rubygems/commit/a18001e10c
|
|
Instead of doing an explicit pass, let sources be replaced while checking
if specifications are up to date.
https://github.com/rubygems/rubygems/commit/676271e804
Notes:
Merged: https://github.com/ruby/ruby/pull/12968
|
|
https://github.com/rubygems/rubygems/commit/e891be9197
Notes:
Merged: https://github.com/ruby/ruby/pull/12968
|
|
Platforms specific gems not compatible with the current Ruby should not
make `bundle cache` fail and should not get removed from the cache since
they still may be useful in other rubies.
https://github.com/rubygems/rubygems/commit/717b43f565
|
|
And make the current `materialize_strictly` private.
https://github.com/rubygems/rubygems/commit/3fc2129147
|
|
We materializing for installation, we already do this, and we
materializing for cache, it does not seem necessary.
https://github.com/rubygems/rubygems/commit/1a983c6cbc
|
|
https://github.com/rubygems/rubygems/commit/32982fcd33
|
|
And rename it to something better.
https://github.com/rubygems/rubygems/commit/321174d1ad
|
|
This gives more flexibility to allow further improvements.
https://github.com/rubygems/rubygems/commit/f11a890f5e
|
|
most_specific_locked_platform
So there's no need to pass it around in so many places.
https://github.com/rubygems/rubygems/commit/784ab7481b
|
|
sometimes
When used with `LazySpecification` objects, `SpecSet#for` was
incorrectly considering development dependencies. This did not cause any
issues because all usages of this method with `LazySpecification`'s are
not strict, meaning the pass `check = false` and ignore incomplete
specifications. But it was still doing more work than necessary because
development dependencies were still added to the `deps` array for
processing and then ignored because of not being found in the spec set.
Same when converging path specifications and replacing their dependencies.
https://github.com/rubygems/rubygems/commit/6afca8a95f
|
|
https://github.com/rubygems/rubygems/commit/ad26ccde38
|
|
https://github.com/rubygems/rubygems/commit/bc2537de71
|
|
https://github.com/rubygems/rubygems/commit/98641d21a2
|
|
https://github.com/rubygems/rubygems/commit/43c0c41c6b
|
|
by installed specs
https://github.com/rubygems/rubygems/commit/6fa94b5d72
|
|
https://github.com/rubygems/rubygems/commit/92196ccfdb
|
|
https://github.com/rubygems/rubygems/commit/8fac200ded
|
|
https://github.com/rubygems/rubygems/commit/a4dd06f095
|
|
https://github.com/rubygems/rubygems/commit/d5dce93167
|
|
I'm running into a case in my plugin where matches_current_metadata? is
getting called on a lazy specification, and adding this fixes it
https://github.com/rubygems/rubygems/commit/24f962cb42
|
|
|
|
https://github.com/rubygems/rubygems/commit/bb66253f2c
|
|
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
|
|
full spec
https://github.com/rubygems/rubygems/commit/957d3d9a7f
|
|
This is a step forward towards eventually including metadata in the
lockfile.
https://github.com/rubygems/rubygems/commit/56fc02b251
|
|
https://github.com/rubygems/rubygems/commit/2462c8e04d
|
|
https://github.com/rubygems/rubygems/commit/5f90a43635
Co-authored-by: Martin Emde <martin.emde@gmail.com>
|
|
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>
|
|
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
|
|
to Bundler.
https://github.com/rubygems/rubygems/commit/d768be0c65
|
|
Sometimes we'll have an heterogenous array of specs which include
`Gem::Specification` objects, which don't define `#identifier`. Let's
use `#full_name` consistently.
Notes:
Merged: https://github.com/ruby/ruby/pull/7582
|
|
Pick from https://github.com/rubygems/rubygems/commit/5ace20dbecfeaf09fba5f616193f3cfcff70ba00
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/6987
|
|
https://github.com/rubygems/rubygems/pull/5960
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/6715
|
|
https://github.com/rubygems/rubygems/commit/6214d00b2315ed37c76b1fbc1c72f61f92ba5a65
Notes:
Merged: https://github.com/ruby/ruby/pull/6578
|
|
https://github.com/rubygems/rubygems/commit/ab11545f80
Notes:
Merged: https://github.com/ruby/ruby/pull/6578
|
|
https://github.com/rubygems/rubygems/commit/ba9d9b1890
Notes:
Merged: https://github.com/ruby/ruby/pull/6578
|
|
Pick from https://github.com/rubygems/rubygems/commit/6b3a5a9ab0453463381a8164efb6298ea9eb776f
Notes:
Merged: https://github.com/ruby/ruby/pull/6268
|