Consider deprecating deployment in favor of separate frozen + path configurations

[deivid-rodriguez]

Describe the problem as clearly as you can

Currently deployment means frozen + path=vendor/bundle. This is a bit obscure and confusing, and it's the only case of a setting that means a combination of two other settings. I think we most likely don't need it.

For now we're in the middle of deprecating remembered flags, so using the --deployment CLI flag recommends using the deployment configuration instead. So, if we decided to do this, we should at least wait until bundler 3 in order to not mess with that deprecation path.

References: #4522.

[indirect]

We might also consider just making frozen and deployment aliases for each other, and separating out path in a deprecation cycle. ¯\_(ツ)_/¯

[deivid-rodriguez]

Yeah, that could work too 👍.

Actually, it just occurred to me that if we made vendor/bundle the default bundle install path (instead of the planned .bundle) everything would be easier, because deployment would change its meaning naturally to exactly that, an alias of frozen, in a backwards compatible way. I think it would also have other advantages like being a path many people is already familiarized with, and allowing committing .bundle/config to source control where it might makes sense without needing cumbersome .gitignore patterns (allow .bundle/config, but exclude anything else in .bundle).

[indirect]

Hmm, interesting! I worry a lot about committing .bundle/config to source control, because it can contain many machine-specific settings (platforms, credentials, local gem paths, etc). Any of those things will break if moved to another machine, so it seems very bad to allow checking in. If you are advanced enough to avoid breaking Bundler by adding those things to your config, I think you are advanced enough to add an exception to your gitignore 😄. But mostly I would recommend telling every user "Bundler does not support checked in config files because there are too many machine-specific settings" or something like that.

The reason I proposed .bundle as the default location was so that it would automatically be excluded from source control, since everyone should already be ignoring that directory. I agree that vendor/bundle would be a location that some people are more familiar with, but I think everyday developers will never have seen that directory, and only developers who maintain deployments will have seen it.

[deivid-rodriguez]

I think we have already discussed whether committing .bundle/config to source control is a good practice or not in the past, and we maintain our disagreement 😃.

Basically, I agree that committing machine specific settings to source control is bad, but committing any other configuration that you want shared with everybody using your application or library seems like a good thing. The thing I like the most about bundler configuration is its flexibility, allowing you to have per-user settings (~/.bundle/config), per-app settings (./.bundle/config), or per machine settings (ENV["BUNDLE_*"]).

I think it's a pretty established practice that libraries have a "per app" configuration that it's fine to commit to source control. Looking at our repo, I can see committed configurations for rubocop, codeclimate, or rspec.

Anyways, this is not terribly urgent, only an idea that came to my mind just now :). We could even consider asking the community and do some poll or something on the different configuration switches to be done for bundler 3.

[deivid-rodriguez]

The reason I proposed .bundle as the default location was so that it would automatically be excluded from source control, since everyone should already be ignoring that directory. I agree that vendor/bundle would be a location that some people are more familiar with, but I think everyday developers will never have seen that directory, and only developers who maintain deployments will have seen it.

Also note that not only for deployment, but vendor/bundle is also very common on CI providers. For example, TravisCI installs to vendor/bundle by default, and also the https://github.com/ruby/setup-ruby GitHub action installs to vendor/bundle by default if you use automatic caching.

[indirect]

Good point! We have recommended that CI use deployment mode for a long time, so that CI can catch any mismatches between Gemfile and lockfile before a deploy blows up. 😄

[deivid-rodriguez]

I thought they set it explicitly through the path setting instead of through the deployment flag, but that's not the case for TravisCI. They explicitly add the deployment flag when there's a lockfile: https://docs.travis-ci.com/user/languages/ruby/#bundler, just like you point out.

[eregon]

IMHO vendor/bundle as default is better, because it's already established (it is what --deployment deploys to by default) and less breaking.
I personally don't see sufficient advantages for .bundle to deserve that additional breakage.

vendor/ seems established as vendored stuff, and having a copy of dependencies certainly feels like vendored software, no? (although automatically installed/updated/etc but that's details, could also be the case for other vendored software).

In either case, I think installing to an app's sub-directory per default in Bundler 3 is a great improvement.

[dentarg]

In either case, I think installing to an app's sub-directory per default in Bundler 3 is a great improvement.

I'm not really following... will it be a folder like node_modules with all the gems code? By default or only if you use deployment? Is there another issue with more info?

[deivid-rodriguez]

By default, exactly like node_modules. This is what I could find for you: rubygems/bundler#3784.