Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bundle package --all fails if BUNDLE_CACHE_ALL is set to true in .bundle/config #3598

Closed
jesseadams opened this issue May 6, 2020 · 3 comments · Fixed by #3914
Closed

bundle package --all fails if BUNDLE_CACHE_ALL is set to true in .bundle/config #3598

jesseadams opened this issue May 6, 2020 · 3 comments · Fixed by #3914
Labels

Comments

@jesseadams
Copy link

  1. Do you have a reproduction script? It would be really helpful for us if you provide one.

With the following barebones Gemfile, or any Gemfile:

source 'https://rubygems.org'

Run:

$ bundle package --all
The Gemfile specifies no dependencies
Resolving dependencies...
Bundle complete! 0 Gemfile dependencies, 1 gem now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.
Updating files in vendor/cache
$ cat .bundle/config
---
BUNDLE_CACHE_ALL: "true"
$ bundle package --all
Unknown switches "--all"
  1. What are you trying to accomplish?

    Your answer: Trying to run bundle package --all consistently in an automated deployment pipeline.

  2. What command did you run?

    Your answer: bundle package --all multiple times during various stages of building a docker image.

  3. What were you expecting to happen?

    Your answer: Bundler to correctly and consistently package the gems

  4. What actually happened?

    Your answer: Bundler correctly packaged the gems the first time and them automatically put BUNDLE_CACHE_ALL: "true" into .bundle/config. The second time running the same command generates the following error: Unknown switches "--all"

  5. Is there an exception backtrace? If so, please copy it below.

    Your answer: No backtrace available

  6. Please run bundle env and paste the output below:

On my local machine:

Environment

Bundler       2.1.4
  Platforms   ruby, x86_64-darwin-18
Ruby          2.7.1p83 (2020-03-31 revision a0c7c23c9cec0d0ffcba012279cd652d28ad5bf3) [x86_64-darwin18]
  Full Path   /usr/local/opt/ruby/bin/ruby
  Config Dir  /usr/local/Cellar/ruby/2.7.1/etc
RubyGems      3.1.2
  Gem Home    /usr/local/lib/ruby/gems/2.7.0
  Gem Path    /Users/jradams/.gem/ruby/2.7.0:/usr/local/lib/ruby/gems/2.7.0:/usr/local/Cellar/ruby/2.7.1/lib/ruby/gems/2.7.0
  User Home   /Users/jradams
  User Path   /Users/jradams/.gem/ruby/2.7.0
  Bin Dir     /usr/local/lib/ruby/gems/2.7.0/bin
Tools
  Git         2.25.1
  RVM         not installed
  rbenv       rbenv 1.1.2
  chruby      not installed
Gem.ruby      /usr/local/opt/ruby/bin/ruby
bundle #!     /usr/local/Cellar/ruby/2.7.1/bin/ruby

Bundler Build Metadata

Built At          2020-01-05
Git SHA           32a4159325
Released Version  true

Bundler settings

cache_all
  Set for your local app (/private/tmp/.bundle/config): true

Gemfile

Gemfile

source 'https://rubygems.org'

Gemfile.lock

GEM
  remote: https://rubygems.org/
  specs:

PLATFORMS
  ruby

DEPENDENCIES

BUNDLED WITH
   2.1.4
@FTLam11
Copy link
Contributor

FTLam11 commented May 9, 2020

It looks like the behavior for --all flag has gone back and forth. The flag is currently removed if Bundler.feature_flag.cache_all? is true.

For anyone that wants to look at the change history: git log -L 439,443:bundler/lib/bundler/cli.rb

@deivid-rodriguez
Copy link
Member

deivid-rodriguez commented May 9, 2020

Right. I've been going back and forth with this over time, trying to figure out what the original plan was and trying to provide a smooth transition.

The quick fix to your problem is to remove the --all flag since the BUNDLE_CACHE_ALL feature flag already provides that behaviour.

But after looking at this again (thanks for the history @FTLam11) I believe rubygems/bundler@04a0471 was wrong because it not only restored the removal of the --all flag on bundler 3, but also on bundler 2 with BUNDLE_CACHE_ALL configured.

Something I'm not clear about is whether the "no path and git" gems in bundle package is something anybody actually want, or whether everyone using path and git gems actually needs to use --all to do something useful with bundle package. In my naive view, it doesn't sound like a use case, so eventually removing the option makes sense.

If removing the option is the preferred approach, then I would:

  • Remove the BUNDLE_CACHE_ALL feature flag and make it the default.
  • Warn on --all usage that the option is redundant and remove it in bundler 3.
  • Remove the warning reading "Your Gemfile contains path and git dependencies. If you want to package them as well, please pass the --all flag. This will be the default on Bundler 3.0". Because it will be the default behavior without alternative.

If on the contrary we consider both --all and --no-all as valid use cases, then I would:

  • Completely revert the removal of the CLI flag.
  • Remove the warning reading "Your Gemfile contains path and git dependencies. If you want to package them as well, please pass the --all flag. This will be the default on Bundler 3.0". Because it's non-actionable and both use cases are considered as valid. The change in the default will be signaled by major version bump and documentation.

@deivid-rodriguez
Copy link
Member

deivid-rodriguez commented Sep 2, 2020

I finally went with:

  • Restore the CLI flag, but deprecate it in favor of bundle config set --local cache_all true, since that's what we've been doing with all the other flags that rely on silently being persisted as configuration after they are run for the first time.

  • The option to cache git and path gems, or not, is still there, and can be configured with bundle config set --local cache_all true or bundle config set --local cache_all false.

  • The default for this option will change in bundler 3 from false to true.

Since I don't really know whether it makes sense or not, to not cache path and git gems, I went with the most conservative option of keeping the choice.

Feel free to give the PR a try!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants