https://github.com/ruby/rubygems/commit/a091e3fd10

* It looked like:
            In a future version of Bundler, running `bundle` without argument will no longer run `bundle install`.
            Instead, the `cli_help` command will be displayed. Please use `bundle install` explicitly for scripts like CI/CD.
            You can use the future behavior now with `bundle config set default_cli_command cli_help --global`,
            or you can continue to use the current behavior with `bundle config set default_cli_command install --global`.
            This message will be removed after a default_cli_command value is set.
  Bundler version 4.0.0 (2025-12-08 commit https://github.com/ruby/rubygems/commit/9b4819ae18)
* And now looks like:
  In a future version of Bundler, running `bundle` without argument will no longer run `bundle install`.
  Instead, the `cli_help` command will be displayed. Please use `bundle install` explicitly for scripts like CI/CD.
  You can use the future behavior now with `bundle config set default_cli_command cli_help --global`,
  or you can continue to use the current behavior with `bundle config set default_cli_command install --global`.
  This message will be removed after a default_cli_command value is set.

  Bundler version 4.0.0 (2025-12-08 commit https://github.com/ruby/rubygems/commit/9b4819ae18)

https://github.com/ruby/rubygems/commit/979dada8f3

* `install_or_cli_help` does not exist for older Bundler like Bundler 2
  and so results in a confusing error on Bundler 2:
  ```
  $ bundle
  Could not find command "".
  ```
* See https://github.com/ruby/rubygems/pull/9136/files#r2592366837
* Merge the behavior of `install_or_cli_help` in `install`.

https://github.com/ruby/rubygems/commit/9b4819ae18

It would be simpler to do `options[:lockfile] ||= ENV["BUNDLE_LOCKFILE"]`,
but that doesn't work as `options` is frozen.

Fixes https://github.com/ruby/rubygems/pull/9117

https://github.com/ruby/rubygems/commit/6e3603a0e9

Co-authored-by: Benoit Daloze <eregontp@gmail.com>

https://github.com/ruby/rubygems/commit/463488b439

Co-authored-by: Patrik Ragnarsson <patrik@starkast.net>

https://github.com/ruby/rubygems/commit/9e44b5ebc4

As mentioned in https://github.com/ruby/rubygems/issues/9124,
the intent for changing the default command was to be more welcoming.

I think we can acheive that by attempting to install, but to print
that same help message if there is no Gemfile.

That should address both concerns.

https://github.com/ruby/rubygems/commit/f3f505c02a

Fix: https://github.com/ruby/rubygems/issues/9124

This behavior is a deeply entrenched convention and changing it
will annoy lots of developers with unclear gains.

https://github.com/ruby/rubygems/commit/628e0ede46

This allows for specifying the lockfile to read and write. It mirrors
the --gemfile option, and has higher priority than the lockfile
method in the Gemfile. It also mirrors the bundle lock --lockfile
option.

When the --lockfile option is used, it is applied twice. First, before
the Gemfile is read, to specify the lockfile to operate on, and again
after the Gemfile is read, so that if the Gemfile has a lockfile
method that overrides the defintion's lockfile, the --lockfile option
still has higher precedence.

https://github.com/ruby/rubygems/commit/17acdd4a89

This allows for the same behavior as including `lockfile false`
in the Gemfile. This allows you to get the behavior without
modifying the Gemfile, which is useful if you do not control the
Gemfile.

This is similar to the --no-lock option already supported by
`gem install -g Gemfile`.

https://github.com/ruby/rubygems/commit/6c94623881

Co-authored-by: Colby Swandale <996377+colby-swandale@users.noreply.github.com>