The "ignore" attribute is a RubyGems thing to mark when a installed gem
should be ignored for activation because its extensions are not properly
compiled.
In the case of gems from path sources, the warning is not accurate
because extensions are compiled into the local lib path, which is not
where RubyGems leaves its sentinel `gem.build_complete` file.
Also, there's a single version of each gem in the path source available
to Bundler, so we always certainly want to consider that for activation
and never makes sense to ignore it.
ec5d33695e
- 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
b9d871022e
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.
e3ec32e247
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.
2353cc93a4
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
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
86c7084e1c
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.
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.
bde37ca6bf
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.
6874bbacce
The commands these specs run were throwing warnings in bundler 2, and
failing on bundler 3, effectively testing a different scenario to what
they were supposed to.
97ac1ced49
Instead, use the non-deprecated option except when specifically testing
deprecated CLI flags. In that case, pass the flag directly and limit
the specs to `bundler < 3`.
3d5e186241
