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
It should be an alias of `--filter-strict`.
`--update-strict` is essentially a dummy option with no special behavior
associated and should be deprecated.
ec1e5d83c8
This is a regression from cf749f8ffa. The
funny thing is that we have a spec for this feature, so it was unclear
how we regressed here. It turns out there was a bug in one of our
negative matchers checking that gems ARE NOT included in a bundle.
This commit fixes the bug in the negative matcher and reverts
cf749f8ffa (with a slightly simpler diff).
3f9a4ff32a
Previously they had slightly different behavior when combined with
conservative updating flags.
The correct behavior is the `--update-strict` option, so `--script` now
does that, The `--update-strict` option is left there for now but I will
deprecate it later.
ab42046229
Test and ensure "false" is handled
Don't use yield_self to operate on autorequire
Remove duplicate autorequire
Add banner to require option
Don't use json to break down require params
Pass linter
a4f2f8ac17
When setting the `RUBYGEMS_GEMDEPS` environment variable to allow
skipping `bundle exec`, `bundler` will print a warning about potential
incompatibility.
Initially the `RUBYGEMS_GEMDEPS` variable used a completely different
(re)implementation of `bundler` functionality. That implementation was
not battle tested and could potentially differ in behaviour from what
`bundler` does. That's why print a warning.
However, these days, all `rubygems` does when `RUBYGEMS_GEMDEPS` is set
is to require `bundler/setup`, so there's no risk of any
incompatibility, since that's just plain `bundler`.
bbddc27016
* bundle gem previously ignored gem.test when passed empty -t flag,
defaulting to RSpec
* bundle gem will now ask user for test framework when passed empty -t
flag and gem.test is set to false, but will not overwrite gem.test
* thor option parsing for String types falls back to human name for nil,
so setting lazy_default to nil won't work
* c5161501e0/lib/thor/parser/options.rb (L224)
Default to Bundler.settings["gem.test"] for empty --test
Add shared examples for test framework to newgem spec
Add examples for empty --test flag to newgem spec
Simplify conditional for prompting test framework
Follow naming conventions for bundler settings
Add more descriptive test framework help text for bundle gem
Update man pages for bundler
ab0785a09f
And never recommend it inside CLI messages.
This flag represents the default behaviour of `bundle install`, and the
only reason it exists is to "override" previous `--deployment` flag
usages which were silently remembered. So it should be deprecated just
like all the other flags the rely on remembering their values across
invocations.
40e50b7190
