The `BUNDLE_` prefix should be reserved to first class settings that
should be listed when running `bundle config`. This one is just a hacky
environment variable that has not corresponding documented setting.
https://github.com/rubygems/rubygems/commit/7e255c5058
fix this failure:
```
configure ... cppflags=-DMJIT_FORCE_ENABLE
...
make test-spec
1)
The -v command line option when used alone prints version and ends FAILED
Expected
"ruby 3.1.0dev (2021-12-18T10:10:42Z master 78c175280b) +MJIT [x86_64-linux]
"
to include "ruby 3.1.0dev (2021-12-18T10:10:42Z master 78c175280b) [x86_64-linux]"
/tmp/ruby/v3/src/trunk-mjit-wait/spec/ruby/command_line/dash_v_spec.rb:9:in `block (3 levels) in <top (required)>'
/tmp/ruby/v3/src/trunk-mjit-wait/spec/ruby/command_line/dash_v_spec.rb:4:in `<top (required)>'
```
http://ci.rvm.jp/results/trunk-mjit-wait@phosphorus-docker/3759943
If we are resolving a dependency against a particular platform, and
there are no platform specific variants of the candidates that match
that platform, we should not consider those candidates.
https://github.com/rubygems/rubygems/commit/f6077fe27d
Linux can allow to bind port 1 to user.
And `ip_unprivileged_port_start` is 0 on [lima](https://github.com/lima-vm/lima) default vm.
```
1)
Socket#bind on SOCK_DGRAM socket raises Errno::EACCES when the current user does not have permission to bind FAILED
Expected Errno::EACCES but no exception was raised (0 was returned)
.../ruby/spec/ruby/library/socket/socket/bind_spec.rb:38:in `block (4 levels) in <top (required)>'
.../ruby/spec/ruby/library/socket/socket/bind_spec.rb:4:in `<top (required)>'
2)
Socket#bind on SOCK_STREAM socket raises Errno::EACCES when the current user does not have permission to bind FAILED
Expected Errno::EACCES but no exception was raised (0 was returned)
.../ruby/spec/ruby/library/socket/socket/bind_spec.rb:79:in `block (4 levels) in <top (required)>'
.../ruby/spec/ruby/library/socket/socket/bind_spec.rb:44:in `<top (required)>'
3)
Socket#bind using IPv4 using a packed socket address raises Errno::EACCES when the user is not allowed to bind to the port FAILED
Expected Errno::EACCES but no exception was raised (0 was returned)
.../ruby/spec/ruby/library/socket/socket/bind_spec.rb:119:in `block (6 levels) in <top (required)>'
.../ruby/spec/ruby/library/socket/socket/bind_spec.rb:85:in `<top (required)>'
4)
Socket#bind using IPv6 using a packed socket address raises Errno::EACCES when the user is not allowed to bind to the port FAILED
Expected Errno::EACCES but no exception was raised (0 was returned)
.../ruby/spec/ruby/library/socket/socket/bind_spec.rb:119:in `block (6 levels) in <top (required)>'
.../ruby/spec/ruby/library/socket/socket/bind_spec.rb:85:in `<top (required)>'
```
Test and ensure "false" is handled
Don't use yield_self to operate on autorequire
Remove duplicate autorequire
Add banner to require option
Don't use json to break down require params
Pass linter
https://github.com/rubygems/rubygems/commit/a4f2f8ac17
This way, if some default gem has been required before bundler, and
rubygems has enhanced the `$LOAD_PATH` to use the latest version in the
system, further requires of that default gem after bundler has been
activated will use the same version and don't cause redefinition
warnings or worse problems derived from the fact of mixing up two
different versions. That, unless the gem is a `Gemfile` dependency. In
that case, we'll get a mismatch error anyways as we do now.
This fix doesn't mean that all default gems internally used by
bundler/rubygems are now supported inside `Gemfile`'s. That should be
handled case by case, but it will now bite people only when they try to
add the gem to their `Gemfile`, not before.
https://github.com/rubygems/rubygems/commit/7325530547
This block of code already wraps file operations with
`SharedHelpers.filesystem_access`, which rescues and re-raises more
friendly errors. Also, I'm not fully sure creating a temporary directory
can end up raising an `Errno::EACCES` error from reading `tmpdir`
sources. Finally, this rescue block apparently leads to some false
positives when firewall is blocking the ruby executable on Windows, or
at least that's what we've got reported.
In any case, I think it's best to let the original error be raised.
https://github.com/rubygems/rubygems/commit/f7dbe54404
Since we no longer have multiple global sources, each top level dependency is
always pinned to a single source, so it makes little sense to talk about
adding or removing a source. Instead, source changes always mean to
change the source one or more dependencies are pinned to. This logic can
now be much simpler.
https://github.com/rubygems/rubygems/commit/f1d33fa0df
We have two representations of a source. Once used for sorting, which
should not depend on the source's state, but solely on its static
information, like remotes. Another one used for error and informational
messages, which should properly inform about the exact state of the
source when the message is printed.
This commit makes the latter be the default implementation of `to_s`, so
that error and informational messages are more accurate by default.
https://github.com/rubygems/rubygems/commit/b5f2b88957
Since the default requirement in rubygems is ">= 0", it was failing to
match 0 prereleases. Changing the default globally to be ">= 0.a"
instead is a major refactoring that's quite tricky to make backwards
compatible, so I'm special casing this where needed for now to fix the
regression.
https://github.com/rubygems/rubygems/commit/68fe37937c
Previously, each of these methods returned self, but it is
more useful to return arguments, to allow for simpler method
decorators, such as:
```ruby
cached private def foo; some_long_calculation; end
```
Where cached sets up caching for the method.
For each of these methods, the following behavior is used:
1) No arguments returns nil
2) Single argument is returned
3) Multiple arguments are returned as an array
The single argument case is really the case we are trying to
optimize for, for the same reason that def was changed to return
a symbol for the method.
Idea and initial patch from Herwin Quarantainenet.
Implements [Feature #12495]
Calling `Bundler.definition.specs` will memoize materialized specs.
However, requiring `bundler/setup` will end up materializing the same
set of specs, but not memoize them.
This change makes things consistent.
https://github.com/rubygems/rubygems/commit/e4c2b52824
We have a quality spec that check for debugger statements. Rubocop has a
cop that tests for the same thing. As such it makes sense to remove the
spec and activate the cop.
https://github.com/rubygems/rubygems/commit/dc1eb6eec5
Even if it's newer than the running versions. Dev versions are not
released to rubygems.org, so the warning message suggests a command that
doesn't work. And dev versions are currently non deterministic
(2.3.0.dev can be many different versions), so the warning doesn't
really make sense at the moment.
https://github.com/rubygems/rubygems/commit/6f31af27ef
We can skip most stuff in `Gem::RemoteFetcher#download`, and use
`Gem::RemoteFetcher#update_cache_path` directly.
This has the benefit of allowing us to remove some workarounds to
support several rubygems versions, but also allows us to pass the target
folder where the gem should be downloaded directly and skip the logic
inside `Gem::RemoteFetcher#download` to infer the cache path. This will
be useful later to fix some issues with the `global_gem_cache` feature
flag.
https://github.com/rubygems/rubygems/commit/8fe74a77e4
Hiroshi SHIBATA
David Rodríguez
Jeremy Evans
Koichi Sasada
Nobuyoshi Nakada
Takashi Kokubun
Vyacheslav Alexeev
Kazuhiro NISHIYAMA
Simon Fish
Jean Boussier
Josef Šimánek
ooooooo-q
Benoit Daloze
Yusuke Endoh
haruuzion
Frederik Dudzik
Frederik Dudzik
Alan Wu
Peter Zhu
180909
TSUYUSATO Kitsune