| Age | Commit message (Collapse) | Author |
|---|
|
changes
When the source used to be git and switches back to rubygems,
it is possible that the git source contains a version that
ruybgems doesn't know about yet.
So don't add the locked spec to the base resolve, and also don't add a
lower bound requirement on the version, since the version in the new
source may actually be lower.
https://github.com/rubygems/rubygems/commit/85514e3a1e
|
|
If the file option is given but the file not found, raise a GemfileError
with a message indicating the file was not found.
Currently this is raising a generic Errno::ENOENT error.
https://github.com/rubygems/rubygems/commit/db61de6b21
|
|
|
|
Set was moved to C only in Ruby 3.5, so it does not compile on Ruby 3.4
and earlier.
|
|
https://github.com/rubygems/rubygems/commit/4919e5ca53
|
|
https://github.com/rubygems/rubygems/commit/573ffad3ea
|
|
docs removed, too
https://github.com/rubygems/rubygems/commit/a727b50697
|
|
--deployment` during specs
https://github.com/rubygems/rubygems/commit/c903afbc3f
|
|
`vlad` entrypoints
Now they only raise an error.
https://github.com/rubygems/rubygems/commit/6e7c8db151
|
|
`Bundler.environment` helpers
https://github.com/rubygems/rubygems/commit/e1b8bdcede
|
|
Followup: https://github.com/ruby/ruby/pull/14463
|
|
the same gem in Gemfile
https://github.com/rubygems/rubygems/commit/e47a9064be
|
|
|
|
in child processes.
`make test-spec SPECOPTS="spec/ruby/command_line/rubyopt_spec.rb -T --yjit"`
fails because `ruby_exe` doesn't seem to propagate options to child processes.
|
|
--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
|
|
Previous implementation included an empty element in the list of
deprecations.
https://github.com/rubygems/rubygems/commit/59eb233039
|
|
previous patch
https://github.com/rubygems/rubygems/commit/fbb8340186
|
|
fixed
https://github.com/rubygems/rubygems/commit/4fc57c69b2
|
|
vendor/cache is empty
https://github.com/rubygems/rubygems/commit/36c5af9156
|
|
Limit the `before` block to set `frozen`, which is the context of the
spec, and change the implementation to only write the Gemfile once, with
a gem being removed from what's in the lockfile.
https://github.com/rubygems/rubygems/commit/4d0314ff37
|
|
https://github.com/rubygems/rubygems/commit/eaa51203ca
|
|
Since the path is changed later by the `deployment` setting, it makes no
difference. So just create a lockfile.
https://github.com/rubygems/rubygems/commit/2dd6f65642
|
|
https://github.com/rubygems/rubygems/commit/a761581e89
|
|
`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/2a2e45bbe9
|
|
Fix for this bug was merged into ruby_3_4 in 5a42d267bfabc86f86cae2e83de24b1b86bc316a
and should go out in the next 3.4.x release.
|
|
Previously, ruby2_keywords could be used on a method or proc with
post arguments, but I don't think the behavior is desired:
```ruby
def a(*c, **kw) [c, kw] end
def b(*a, b) a(*a, b) end
ruby2_keywords(:b)
b({foo: 1}, bar: 1)
```
This changes ruby2_keywords to emit a warning and not set the
flag on a method/proc with post arguments.
While here, fix the ruby2_keywords specs for warnings, since they
weren't testing what they should be testing. They all warned
because the method didn't accept a rest argument, not because it
accepted a keyword or keyword rest argument.
|
|
We had them duplicated, but with slightly different features:
* The ones in `other/cli_man_pages.rb` enforced a specific structure to
document CLI options, so were less likely to have false positives.
* The ones in `quality_spec.rb` were able to check subcommands and their
flags.
This commit merges both and preserves the best of both.
|
|
https://github.com/rubygems/rubygems/commit/05199ae0c1
|
|
https://github.com/rubygems/rubygems/commit/d41b8d303c
|
|
To save some unnecessary `bundle install` commands.
https://github.com/rubygems/rubygems/commit/61e7d9d09a
|
|
We had actually cancelled this change. After a second look though, it
does seem like a reasonable plan since `bundle list` makes more sense
for listing gems, and `bundle info` makes more sense for showing info
about a particular gem. `bundle show` is a strange mix of both.
Let's schedule this for Bundler 5.
https://github.com/rubygems/rubygems/commit/7071a1e82e
|
|
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
|
|
For consistency.
https://github.com/rubygems/rubygems/commit/3e3364e19f
|
|
https://github.com/rubygems/rubygems/commit/4d0c058e6a
|
|
Since the lowest supported version is now 3.4.1.
https://github.com/rubygems/rubygems/commit/d00e03c52e
|
|
Platform specific versions of ffi-1.17.2 are not compatible with Ruby
3.5, so Bundler fails to resolve in Ruby 3.5 using recorded VCR
responses.
Use the generic version of ffi-1.17.2, which should work for all rubies,
consistently to fix that.
https://github.com/rubygems/rubygems/commit/a192f7e35d
|
|
https://github.com/rubygems/rubygems/commit/781443cb0f
|
|
Bumps [thor](https://github.com/rails/thor) from 1.3.2 to 1.4.0.
- [Release notes](https://github.com/rails/thor/releases)
- [Commits](https://github.com/rails/thor/compare/v1.3.2...v1.4.0)
---
updated-dependencies:
- dependency-name: thor
dependency-version: 1.4.0
dependency-type: indirect
...
Signed-off-by: dependabot[bot] <support@github.com>
https://github.com/rubygems/rubygems/commit/0a4e5a377d
|
|
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
|
|
|
|
There are several issues with these which I'm not sure I'll have time to
address properly. I prefer to keep our default branch in a releasable
state just in case. Once they are fixed, this can be reverted.
|
