| Age | Commit message (Collapse) | Author |
|---|
|
the same gem in Gemfile
https://github.com/rubygems/rubygems/commit/e47a9064be
|
|
control
--append adds a source to the end, moving it to the end if it already exists.
--prepend adds or moves a source to the beginning.
This allows idempotent sorting of gem sources without removing and adding.
https://github.com/rubygems/rubygems/commit/d9a0567c65
|
|
Since Ruby 3.4.5, which ships with did_you_mean-2.0.0, RubyGems no
longer gives "did you mean" suggestions for unknown commands.
This is because did_you_mean-2.0.0 completely removed the SPELL_CHECKERS
constant, and attaching "did you mean" to `Gem::UnknownCommandError`
errors required this constant to be defined.
The fix is to remove conditions on the `SPELL_CHECKERS` constant.
https://github.com/rubygems/rubygems/commit/9287cd80ed
|
|
only configured sources
https://github.com/rubygems/rubygems/commit/ef78de5b69
|
|
sources`
"Not present in cache" felt a bit unclear, so I changed the reason to:
"No configured sources" or "source not present in configured sources",
also pointing explicitly to the configuration file where RubyGems is
looking for the source to be removed.
https://github.com/rubygems/rubygems/commit/2bae554eff
|
|
https://github.com/rubygems/rubygems/commit/0ccf323734
|
|
https://github.com/rubygems/rubygems/commit/d86d9b3596
|
|
displaying
https://github.com/rubygems/rubygems/commit/2afefa4a48
|
|
This approach better simulate that ["http://gems.example.com/"] is the
default list of sources, rather than ["https://rubygems.org/"].
https://github.com/rubygems/rubygems/commit/55130c259a
|
|
--no-prune`
Since they are remembered flags, too.
I also restored a previous spec about `--frozen`, but didn't bother with
`--no-prune`.
https://github.com/rubygems/rubygems/commit/7802f016fc
|
|
vendor/cache is empty
https://github.com/rubygems/rubygems/commit/36c5af9156
|
|
`lockfile` flags:
- Ref #8917
- ### Problem
Prior to Bundler 2.5.6, running
`bundle lock --update foo --lockfile Gemfile_bumped.lock` would
update only the foo gem and write the lockfile to the
`Gemfile_bumped.lock`.
In Bundler 2.5.6 and above running the same command, updates
absolutely all gems.
This change is related to #7047
### Solution
We decided to expose the `write_lock` method rather than going
through a complex deprecation cycle of the `lock` method.
This commit applies the same business logic as prios to 2.5.6 where,
we build the definition using the existing lockfile, make changes to
the definition and dump it into the desired lockfile.
https://github.com/rubygems/rubygems/commit/c88f00c41d
|
|
|
|
|
|
To directly raise regardless of version.
https://github.com/rubygems/rubygems/commit/38fb97cffa
|
|
https://github.com/rubygems/rubygems/commit/6c2b06cc16
|
|
https://github.com/rubygems/rubygems/commit/eab6366e2e
|
|
https://github.com/ruby/error_highlight/commit/d3063cde62
|
|
... as it is already EOL
https://github.com/ruby/error_highlight/commit/f15489216a
|
|
arguments" error
This is an experimental implementation for
https://bugs.ruby-lang.org/issues/21543.
```
test.rb:2:in 'Object#foo': wrong number of arguments (given 1, expected 2) (ArgumentError)
caller: test.rb:6
| foo(1)
^^^
callee: test.rb:2
| def foo(x, y)
^^^
from test.rb:6:in 'Object#bar'
from test.rb:10:in 'Object#baz'
from test.rb:13:in '<main>'
```
https://github.com/ruby/error_highlight/commit/21e974e1c4
|
|
https://github.com/ruby/syntax_suggest/commit/54bb8ab330
|
|
https://github.com/rubygems/rubygems/commit/b58829a868
|
|
https://github.com/rubygems/rubygems/commit/05199ae0c1
|
|
https://github.com/rubygems/rubygems/commit/d41b8d303c
|
|
Make synopsis, subcommands, and CLI flags use a format consistent with
the other docs, and also reword some sentences for clarify.
https://github.com/rubygems/rubygems/commit/9272169ad0
|
|
Name default value placeholders in a more standard way. That's what our
specs check, but they don't yet work for subcommand flags.
https://github.com/rubygems/rubygems/commit/c589899cb8
|
|
For synopsis, subcommand and flag documentation like other commands do.
https://github.com/rubygems/rubygems/commit/f528029756
|
|
https://github.com/rubygems/rubygems/commit/2cbe7ea0a5
|
|
alternative to `bundle show --outdated`
https://github.com/rubygems/rubygems/commit/7cad1e4947
|
|
specific case
If upgrading `foo` needs an indirect dependency to be downgraded,
Bundler would not be able to upgrade foo.
This is because when calculating the latest resolvable version of foo,
Bundler was still adding lower bound requirements on the locked versions
of all dependencies to avoid downgrades, effectively pinning foo to a
version older than the latest.
To fix this, instead of creating a second "unlocked" definition to
figure out the latest resolvable version, create a second unlocked
resolver, and DO NOT add lower bound requirements to it.
https://github.com/rubygems/rubygems/commit/00cc0ecc69
|
|
The `bundle list` command is a convenient way for human to know what gems and versions are available. By introducing a `--format=json` option, we can provide the same information to machines in a stable format that is robust to UI additions or modifications. It indirectly supports `Gemfile.lock` modifications by discouraging external tools from attempting to parse that format.
This addition allows for the scripting of installation tools, such as buildpacks, that wish to branch logic based on gem versions. For example:
```ruby
require "json"
command = "bundle list --format=json"
output = `#{command}`
raise "Command `#{command}` errored: #{output}" unless $?.success?
railties = JSON.parse(output).find {|gem| gem["name"] == railties }
if railties && Gem::Version.new(railties["version"]) >= Gem::Version.new("7")
puts "Using Rails greater than 7!"
end
```
The top level is an object with a single key, "gems", this structure allows us to add other information in the future (should we desire) without having to change the json schema.
https://github.com/rubygems/rubygems/commit/9e081b0689
|
|
verbose mode
This reverts commit https://github.com/rubygems/rubygems/commit/bea87eab0b17 and adds a
regression spec for it.
https://github.com/rubygems/rubygems/commit/ac98107864
|
|
warning
Like others, it's a remembered option which we are deprecating in favor
of configuration.
https://github.com/rubygems/rubygems/commit/9ea55e0df2
|
|
https://github.com/rubygems/rubygems/commit/0e92346d88
|
|
The current oldest support Ruby version is 3.2. And Ruby 3.2 bundled
Bundler 2.5. It means RG 4.0 can drop to support Bundler 2.2.
https://github.com/rubygems/rubygems/commit/592ac09b5c
|
|
Generally I have been good about safely accessing the tokens but failed
to properly guard against no tokens in places
where it could theoretically happen through invalid syntax.
I added a test case for one occurance, other changes are theoretical only.
https://github.com/ruby/prism/commit/4a3866af19
|
|
Uses ::RbConfig::CONFIG['host_os']
Found with ruby --disable-gems -e '...'
https://github.com/ruby/resolv/commit/5a5a81ce98
|
|
https://github.com/ruby/optparse/commit/2f9c7500a3
|
|
https://github.com/rubygems/rubygems/commit/e09a6ec815
|
|
https://github.com/rubygems/rubygems/commit/29c085f5f5
|
|
https://github.com/rubygems/rubygems/commit/fa1c51ef59
|
|
rubygems_deprecate_command without rubygems.rb
https://github.com/rubygems/rubygems/commit/4925403686
|
|
at RG 4.1
https://github.com/rubygems/rubygems/commit/e99cdab171
|
|
next major
https://github.com/rubygems/rubygems/commit/15177de84e
|
|
https://github.com/rubygems/rubygems/commit/120c174e7f
|
|
The purpose of this commit is to fix Bug #21188. We need to detect when
stdin has run in to an EOF case. Unfortunately we can't _call_ the eof
function on IO because it will block.
Here is a short script to demonstrate the issue:
```ruby
x = STDIN.gets
puts x
puts x.eof?
```
If you run the script, then type some characters (but _NOT_ a newline),
then hit Ctrl-D twice, it will print the input string. Unfortunately,
calling `eof?` will try to read from STDIN again causing us to need a
3rd Ctrl-D to exit the program.
Before introducing the EOF callback to Prism, the input loop looked
kind of like this:
```ruby
loop do
str = STDIN.gets
process(str)
if str.nil?
p :DONE
end
end
```
Which required 3 Ctrl-D to exit. If we naively changed it to something
like this:
```ruby
loop do
str = STDIN.gets
process(str)
if STDIN.eof?
p :DONE
end
end
```
It would still require 3 Ctrl-D because `eof?` would block. In this
patch, we're wrapping the IO object, checking the buffer for a newline
and length, and then using that to simulate a non-blocking eof? method.
This commit wraps STDIN and emulates a non-blocking `eof` function.
[Bug #21188]
|
|
Paths in environment variables should already be expanded.
The base name of the program is also not subject to expansion.
https://github.com/ruby/optparse/commit/181752391c
|
|
https://github.com/ruby/prism/commit/9f55551b09
|
|
https://github.com/ruby/prism/commit/c2e372a8d8
|
|
|
