| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
preview
When using a Ruby preview the require path of `bundler/setup` is
similar to `-r/opt/ruby3.3.0-preview2/lib/ruby/3.3.0+0/bundler/setup`.
The special character `+` in the string makes the Regexp fail,
leading to multiple addition of the same require statement each time
`set_rubyopt` is called (e.g. server reloading).
Escaping the characters in the string esure a correct match with all
the different Ruby versions.
https://github.com/rubygems/rubygems/commit/dd43dfa709
|
|
|
|
| |
The test for integer part was separated at dc54574adefe.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As discussed in https://github.com/rubygems/rubygems/issues/6273#issuecomment-1449176658
The `gem` method behaves awkwardly in standalone mode. Assuming bundler
isn't loaded at all, a call to gem might activate a gem that is not part
of the bundle (because it's the gem method defined in
lib/rubygems/core_ext/kernel_gem.rb and not
lib/bundler/rubygems_integration.rb). And when running with
`--disable-gems`, the gem method won't be defined at all so we'll get a
NoMethodError.
Calls to `gem` can appear in dependencies outside an application's
control. To work around this at GitHub we defined our own `Kernel#gem`
that no-ops.
I agree with https://github.com/rubygems/rubygems/issues/6273#issuecomment-1440755882
> people using standalone mode don't want to activate gems like Kernel.gem
This commit redefines `Kernel#gem` in the standalone script to no-op.
https://github.com/rubygems/rubygems/commit/bea17b55f1
|
|
|
|
|
|
| |
prereleases
https://github.com/rubygems/rubygems/commit/d76dc70d90
|
|
|
|
| |
https://github.com/rubygems/rubygems/commit/64e7a2656a
|
|
|
|
|
|
|
| |
- Specs for GitProxy were incorrect and insufficient
- Specs are now correct and less insufficient
https://github.com/rubygems/rubygems/commit/63d0a8cfd0
|
|
|
|
| |
https://github.com/rubygems/rubygems/commit/2851e051c3
|
|
|
|
|
| |
Remove the bad example that can lead to misunderstanding as if this
precision is defined in Ruby.
|
| |
|
|
|
|
|
|
| |
3.3.0-preview2) in Gemfile
https://github.com/rubygems/rubygems/commit/4c1a0511b6
|
|
|
|
| |
https://github.com/rubygems/rubygems/commit/042cfb7007
|
| |
|
|
|
|
|
|
| |
When a path does not make a lot of sense.
https://github.com/rubygems/rubygems/commit/d173c79e9a
|
|
|
|
| |
https://github.com/rubygems/rubygems/commit/a30712c0fc
|
|
|
|
|
|
|
|
| |
When the latest allowed minor of `dep` adds a new dependency, that new
dependency would be incorrectly resolved to the latest minor of the
first major version.
https://github.com/rubygems/rubygems/commit/fd50c9d4f3
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were setting the wrong `extension_dir` for git specs stubs
Additionally, the call to `self.extension_dir` was loading the
remote spec, which was avoidable since the stub had an extension dir
(and in fact its #gem_build_complete_path does exactly what we want
anyway)
Finally, now set the base_dir when loading the remote_spec from a
stub specification, since the git source sets the base dir for stubs
based on where the spec _will_ be installed to, and we want to preserve
that so the base_dir for the loaded spec & the stub are the same
https://github.com/rubygems/rubygems/commit/a94acb465b
|
|
|
|
| |
https://github.com/rubygems/rubygems/commit/63b422b71a
|
|
|
|
| |
https://github.com/rubygems/rubygems/commit/ccb1bb5d3a
|
|
|
|
|
|
| |
Increase test coverage and be explicit about what is and is not supported.
https://github.com/rubygems/rubygems/commit/a096397a00
|
|
|
|
|
| |
It failed with `NameError` because `Html3` is defined in the file that
`CGI::HtmlExtension` autoloads.
|
|
|
|
|
|
| |
Ensure unrecognized SPECS types are ignored
https://github.com/rubygems/rubygems/commit/5b33e91075
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, Kernel#lambda returned a non-lambda proc when given a
non-literal block and issued a warning under the `:deprecated` category.
With this change, Kernel#lambda will always return a lambda proc, if it
returns without raising.
Due to interactions with block passing optimizations, we previously had
two separate code paths for detecting whether Kernel#lambda got a
literal block. This change allows us to remove one path, the hack done
with rb_control_frame_t::block_code introduced in 85a337f for supporting
situations where Kernel#lambda returned a non-lambda proc.
[Feature #19777]
Co-authored-by: Takashi Kokubun <takashikkbn@gmail.com>
|
| |
|
| |
|
|
|
|
| |
https://github.com/rubygems/rubygems/commit/98da5b9826
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[Bug #19012]
man recvmsg(2) states:
> Return Value
> These calls return the number of bytes received, or -1 if an error occurred.
> The return value will be 0 when the peer has performed an orderly shutdown.
Not too sure how one is supposed to make the difference between a packet of
size 0 and a closed connection.
|
|
|
|
|
|
| |
It now does the redownloading/installing just like bundle install --redownload
https://github.com/rubygems/rubygems/commit/3b058e5eca
|
|
|
|
| |
https://github.com/rubygems/rubygems/commit/c969a192bf
|
|
|
|
| |
https://github.com/rubygems/rubygems/commit/d275cdccb1
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
https://github.com/rubygems/rubygems/commit/f664d60114
|
|
|
|
|
|
| |
- String#start_with?
- String#delete_prefix
- String#delete_prefix!
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
| |
* Skip RBS test.
|
|
|
|
|
|
|
|
|
|
|
| |
https://github.com/ruby/ruby/actions/runs/5956398507/job/16157091112
This has been extremely flaky on macOS GitHub Actions.
Benoit suggested to quarantine it if it's too problematic (it is) and
there's no reasonable fix in a short time (it already took too long).
So this commit follows the suggestion.
We should remove revert this once rb_cloexec_open() is fixed.
|