| Age | Commit message (Collapse) | Author |
|---|
|
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/53e0490b55
|
|
Otherwise you can have work in some circumstance but not in others.
|
|
Daily Bundler CI against ruby-head is failing because ruby-head now
uses bigdecimal 3.1.5, so that gets locked by this spec.
This change should make the test stable until bigdecimal 99.1.5 is
bundled with Ruby :)
https://github.com/rubygems/rubygems/commit/830326041f
|
|
in Bundler specs
We want to avoid any "user home" fallbacks, since that won't work with
Bundler.
So if there's a permissions issue during specs, it's best to raise
immediately.
https://github.com/rubygems/rubygems/commit/767a3e7533
|
|
This command is not expected to fail. If it fails, we can stop the test.
https://github.com/rubygems/rubygems/commit/2511a5b093
|
|
https://github.com/rubygems/rubygems/commit/2eb2860e9e
|
|
foo.gemspec was added in
rubygems/rubygems@8d699ed096960ed9a6636bd27143952ff5f8addc but was not
sync'd in commit b4bf8c9ee2d716adf5fc08e67c4b26d6a8f929c2. This causes
the spec to fail.
|
|
Since #6945 the extension dir changed to Gem::BasicSpecification's implementation, we didn't hook that in rubygems_ext.rb. So for universal rubies, we ended up using the universal platform name when installing, but arch replaced platform name when checking. This lead to native extensions can never be correctly installed on universal rubies.
Hook Gem::BasicSpecifications so the behavior is consistent on installing and checking.
https://github.com/rubygems/rubygems/commit/8d699ed096
|
|
Comparing file paths as strings may not work well for some reasons,
symlink, relative `__FILE__`, etc.
Some alternatives are possible: comparing with `File.realpath`, or
with `File.identical?`, it should be most robust to escape the target
string contained within this file itself.
|
|
https://github.com/rubygems/rubygems/commit/3e7f1379fb
|
|
https://github.com/rubygems/rubygems/commit/e41156e272
|
|
writable bit
Instead, don't check that at all and proceed. If something fails to be
written inside GEM_HOME, we'll eventually fail with a proper permissions
error.
In addition to that, the writable bit in GEM_HOME is not even reliable,
because only the immediate parent is actually checked when writing. For
example,
```
$ mkdir -p foo/bar
$ chmod -w foo
$ touch foo/bar/baz # writes without issue
```
https://github.com/rubygems/rubygems/commit/4bced7ac73
|
|
|
|
LibreSSL seems not to support `scrypt`.
https://rubyci.s3.amazonaws.com/openbsd-current/ruby-master/log/20231105T233005Z.fail.html.gz
```
1)
OpenSSL::KDF.scrypt creates the same value with the same input ERROR
NoMethodError: undefined method `scrypt' for module OpenSSL::KDF
```
|
|
https://github.com/rubygems/rubygems/commit/8d51390ca4
|
|
|
|
Do not use a variable as a format string. Also we usually don't
expect non-ascii data in C string literals.
|
|
|
|
|
|
This reverts commit d434765faead1583ca9008bb579067a288085b93.
|
|
|
|
|
|
https://github.com/rubygems/rubygems/commit/a89f74c27e
|
|
Enable the test commented out in ruby/ruby@d0f5dc9eac78ecade459.
Extracted from GH-7033, that is for initialization at start up time
and this test is unrelated to it.
|
|
Gem::Specification#files
https://github.com/rubygems/rubygems/commit/4bb0ef3e55
|
|
https://github.com/rubygems/rubygems/commit/7c0afdd9af
|
|
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/af61829432
|
|
For some reason, Windows builds are failing quite consistently now.
However, it seems that errors are happening before this directory is
even created, so removal fails, hiding the original error.
Instead, don't let this removal fail due to files not existing.
https://github.com/rubygems/rubygems/commit/7669d6c96e
|
|
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
|
|
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
|
|
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
|
|
|
|
This patch introduce M:N thread scheduler for Ractor system.
In general, M:N thread scheduler employs N native threads (OS threads)
to manage M user-level threads (Ruby threads in this case).
On the Ruby interpreter, 1 native thread is provided for 1 Ractor
and all Ruby threads are managed by the native thread.
From Ruby 1.9, the interpreter uses 1:1 thread scheduler which means
1 Ruby thread has 1 native thread. M:N scheduler change this strategy.
Because of compatibility issue (and stableness issue of the implementation)
main Ractor doesn't use M:N scheduler on default. On the other words,
threads on the main Ractor will be managed with 1:1 thread scheduler.
There are additional settings by environment variables:
`RUBY_MN_THREADS=1` enables M:N thread scheduler on the main ractor.
Note that non-main ractors use the M:N scheduler without this
configuration. With this configuration, single ractor applications
run threads on M:1 thread scheduler (green threads, user-level threads).
`RUBY_MAX_CPU=n` specifies maximum number of native threads for
M:N scheduler (default: 8).
This patch will be reverted soon if non-easy issues are found.
[Bug #19842]
|
|
https://github.com/rubygems/rubygems/commit/6b21f593f3
|
|
GEM_HOME always overide it.
https://github.com/rubygems/rubygems/commit/64273fd7e3
|
|
"bundle doctor" specs.
https://github.com/rubygems/rubygems/commit/d7f3f901f1
|
|
more than once
https://github.com/rubygems/rubygems/commit/6485adda54
|
|
before 3.2 on windows
https://github.com/rubygems/rubygems/commit/834ae8a29a
|
