| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
|
|
Fixes a TODO now that no reports have been reported in a while.
https://github.com/rubygems/rubygems/commit/f10dc84e7b
|
|
https://github.com/rubygems/rubygems/commit/8078a747b3
|
|
there's no lockfile
The generic Ruby platform was getting unconditionally added in
truffleruby, preventing resolution in situations where there's no
generic ruby version (sorbet-static). Instead, the generic platform
should be considered per dependency, not globally.
https://github.com/rubygems/rubygems/commit/a96afc5351
|
|
Original issue was fixed in JRuby 9.3.0.0, which seems old enough for us
to remove the workaround.
https://github.com/rubygems/rubygems/commit/d285148d39
|
|
After digging into git history a bit, I figure this was about unifying
`bundle cache` and `bundle package`, which already happened a while ago.
So remove this TODO since it's now misleading.
https://github.com/rubygems/rubygems/commit/5a0b06b84d
|
|
This makes it hard to do version checks against this value. The current version checks work because there are so few possible values at the moment.
As an example, PR 3337 introduces new syntax for ruby 3.5 and uses `PM_OPTIONS_VERSION_LATEST` as its version guard. Because what is considered the latest changes every year, it must later be changed to `parser->version == parser->version == PM_OPTIONS_VERSION_CRUBY_3_5 || parser->version == PM_OPTIONS_VERSION_LATEST`, with one extra version each year.
With this change, the PR can instead write `parser->version >= PM_OPTIONS_VERSION_CRUBY_3_5` which is self-explanatory
and works for future versions.
https://github.com/ruby/prism/commit/8318a113ca
|
|
Adds a link to the GitHub Releases page for this gem consistent with other gems in the Ruby organization. Existing examples include:
- [json](https://github.com/ruby/json/blob/master/json.gemspec)
- [ostruct](https://github.com/ruby/ostruct/blob/master/ostruct.gemspec)
https://github.com/ruby/tsort/commit/8086bb33bc
|
