[Bug #20593]
It's fairly common to use `format` to interpolate a number of values
into a user provided strings.
The arguments not matching are a problem when they are positional,
but when they are named, it's absolutely fine and we shouldn't
emit a warning.
If there's a lockfile, but it's out of sync with the Gemfile because a
dependency has been deleted, and frozen mode is set, Bundler will print
the following strange error:
```
$ bundle add rake
, but the lockfile can't be updated because frozen mode is set
You have deleted from the Gemfile:
* rake (~> 13.2)
Run `bundle install` elsewhere and add the updated Gemfile to version control.
```
This commit changes the error to:
```
Some dependencies were deleted from your gemfile, but the lockfile can't be updated because frozen mode is set
You have deleted from the Gemfile:
* rake (~> 13.2)
Run `bundle install` elsewhere and add the updated Gemfile to version control.
```
https://github.com/rubygems/rubygems/commit/452da4048d
If Gemfile is empty and there's no lockfile (situation after `bundle init`), and
`frozen` is configured, running `bundle add` will result in an strange
error, like this:
```
$ bundle add rake
, but the lockfile can't be updated because frozen mode is set
You have deleted from the Gemfile:
* rake (~> 13.2)
Run `bundle install` elsewhere and add the updated Gemfile to version control.
```
This commit fixes the problem to instead print
https://github.com/rubygems/rubygems/commit/152331a9dc
While working on something else I noticed:
* Usage of uppercased "RUBY" and "JAVA" as platforms, when those don't
really exist.
* Usage of some test gems with "1.0" as gemspec version and "1.0.0" as
actual version.
This commit fixes both inconsistencies to make things more expectable.
https://github.com/rubygems/rubygems/commit/e3ec32e247
Previously, a TypeError was not raised if there were no thread
variables, because the conversion to symbol was done after that
check. Convert to symbol before checking for whether thread
variables are set to make the behavior consistent.
Fixes [Bug #20606]
Instead, build it during setup when in CI.
This should avoid some Windows specific test failures when Bundler
copies the same files from multiple processes and runs into EACESS
errors.
https://github.com/rubygems/rubygems/commit/c194a1d753
This commit switches out the full gemspec validation for a partial one
which only performs resolution related checks. This will allow gem
authors to run `bundle` commands immediately after creating a new gem
with Bundler, rather than having to fix metadata validation issues in
the default gemspec.
https://github.com/rubygems/rubygems/commit/d5aa9cae9d
If $HOME isn't a valid directory, these specs fail, but I think it
is better to skip in this case, as it does not indicate a bug.
This fixes specs when run in the OpenBSD port, which sets $HOME
to an invalid directory to ensure that software's build system
is not accidentally relying on it.
When locked only to RUBY, and some locked spec does not meet locked
dependencies, Bundler would remove the only locked platform and end up
creating a lockfile with empty sections.
We can't rely on our criteria to remove invalid platforms if locked
specs are not valid in the first place.
https://github.com/rubygems/rubygems/commit/1dba05cf53
Calling `remote!` or `cached!` on the source was expiring local specs
for now reason. It's unnecessary to override these methods for path
sources since they only deal with local specifications.
https://github.com/rubygems/rubygems/commit/aa93b196a2
If RUBY is the only platform in the lockfile, we were skipping adding
the local platform to the list of resolution platforms. This generally
works anyways, because we had some code to still add it if the RUBY
platform is not valid for the set of locked gems.
However, sometimes it can happen that "RUBY" is valid for the current
set of locked gems, but when adding a new dependency, it becomes
invalid. For example, when adding sorbet to a Gemfile, that will
introduce `sorbet-static` as an indirect dependency which does not have
a generic "RUBY" variant. This will cause resolution to take a long time
continuously backtracking trying to find solutions that don't introduce
`sorbet-static` as a dependency and will eventually fail.
Instead, we can always add the local platform to the set of resolution
platforms before resolving, and remove it as necessary after resolution
so that we lock the correct set of platforms.
https://github.com/rubygems/rubygems/commit/6ed1fe6050
* The string search parser was more memory efficient but
in some cases, much slower. Reverting until a better
solution is found.
* Handle the situation where the line might be blank (Artifactory bug)
https://github.com/rubygems/rubygems/commit/222d38737d
Hiroshi SHIBATA
David Rodríguez
Nobuyoshi Nakada
Jean Boussier
Jean Boussier
Jeremy Evans
Jerome Dalbert
Andrew Konchin
Thomas Marshall
Martin Emde
Earlopain