This error message is also printed when using `bundler/setup` in frozen
model, so we're not necessarily installing any gems when it happens.
This new message play nicer with all situations.
6874bbacce
Similarly to how the other ignored files are intended for local
development and not for production, the Gemfile and Gemfile.lock files
for a gem only relate to local development and aren't useful to people
installing the gem.
59049c04be
While working on locking multiple platforms by default, I got an
infinite resolution loop in one of our resolver specs.
The culprit ended up being that when dealing with lockfile specs with
incomplete dependencies (spec appears in lockfile, but its dependencies
don't), those specs were not being properly expired and that tripped up
resolution.
The issue for some reason only manifests when dealing with multiple
lockfile platforms, that's why it only manifested when working on
locking multiple platforms by default.
4ca72913bb
Bundler is very conservative by default, trying to preserve versions
from the lockfile as possible, and never downgrading them. However, when
it runs into a resolution error, it still tries to find a valid
resolution.
This fallback behavior was too "brute-force" though, completely
unrestricting any gem found in the resolution conflict, and that could
lead to direct dependencies being downgraded in some edge cases.
Instead, unlock things a bit more carefully:
* First try unlocking fully pinned indirect dependencies, but leave a
lower bound requirement in place to prevent downgrades.
* Then try unlocking any fully pinned dependency, also leaving a lower
bound requirement in place.
* Finally completely unrestrict dependencies if nothing else worked.
7f55ed8302
Since Bundler 2.4, we will try to checkout any branch specified in the
Gemfile, while until Bundler 2.3 we would directly checkout the locked
revision.
This should not make any difference in most situations, but in some edge
cases, like if the branch specified in the `Gemfile` has been renamed,
but the locked revision still exist, it causes an error now while before
it would update the lockfile without issues.
I debated which behavior was best, since I was not sure. But my
conclusion is that if the situation does not require expiring the
lockfile source in favor of the Gemfile source, we should use the locked
revision directly and proceed happily. So I restored Bundler 2.3
behavior.
I think this is consistent with how yanked gems are handled, for example.
Of course, if explicitly updating the git source itself, or all gems, we
will still get any errors like missing branches related to the git source.
This was working fine for direct dependencies using
`force_ruby_platform` explicitly through Gemfile, but not for indirect
dependencies. In general, indirect dependencies do not have this
property set, but in truffleruby this is different and the default value
is to have it set.
This should be a very rare edge case, however, it does happen when using
a .dev version of Bundler because in that case, that's the only version
that the resolver considers, and it should not be ignored.
We could've special cased this specifically for Bundler, but I think it
does make sense for every gem.
If the original `BUNDLE_GEMFILE` is different from the default, then the
suggestion wouldn't work as is.
Before:
```
$ util/rubocop
Could not find rubocop-1.30.1 in locally installed gems
Run `bundle install` to install missing gems.
$ rubygems git:(better-cmd-suggestion) ✗ bundle install
Could not locate Gemfile
```
After:
```
$ util/rubocop
Could not find rubocop-1.30.1 in locally installed gems
Run `bundle install --gemfile /path/to/rubygems/bundler/tool/bundler/lint_gems.rb` to install missing gems.
$ bundle install --gemfile /path/to/rubygems/bundler/tool/bundler/lint_gems.rb
Fetching gem metadata from https://rubygems.org/.........
Using ast 2.4.2
Using bundler 2.4.7
Using parser 3.1.2.0
Using rainbow 3.1.1
Using parallel 1.22.1
Using regexp_parser 2.5.0
Using rubocop-ast 1.18.0
Using rexml 3.2.5
Using ruby-progressbar 1.11.0
Using unicode-display_width 2.1.0
Fetching rubocop 1.30.1
Installing rubocop 1.30.1
Using rubocop-performance 1.14.2
Bundle complete! 2 Gemfile dependencies, 12 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.
$ util/rubocop
Inspecting 345 files
.........................................................................................................................................................................................................................................................................................................................................................
345 files inspected, no offenses detected
```
bf1320d805
* Replaces the wording of "is forbidden" with "cannot be used"
* Fixes the method signature of VersionRange::Empty#eql?
8c6b3f130b
Co-authored-by: Daniel Colson <danieljamescolson@gmail.com>
The previous code loads bundler's gemspec which does not include the generated
gemspec file, and thus the test was passing where it should indeed fail.
With this change, the test properly fails now.
2098ea0d75
Prior to this commit `bundle binstubs --standalone --all` would output a
warning about not being able to generate a standalone binstub for
bundler.
This warning predates the `--all` option, and I don't think it makes
sense in this context. The warning makes good sense when explicitly
trying to generate a bundler standalone binstub with `bundle binstubs
bundler --standalone`, since that command won't do what the user might
have expected. But `--all` is not specifically asking for bundler, and
having it report each time that the bundler binstubs could not be
generated does not seem particularly helpful. The only way to make that
warning go away would be to stop using `--standalone --all`.
This commit skips the warning when running with the `--all` option.
e6a72e19eb
bundle lock --update can do everything that bundle update can do, but
it doesn't actually install gems. This is especially useful for
generating a lockfile on a machine that doesn't have the libraries
available to be able to build native extensions.
But, there was no parallel for bundle update --bundler. So let's add
one.
7fc00bd2a5
This allows the file to be created without copying permissions
from Bundler's installation source. The previous behaviour was
noticed after installing Ruby through brew, and using bundle
init, which yielded a read-only Gemfile.
839a06851d
