Enable `default_install_uses_path` by default

[deivid-rodriguez]

default_install_uses_path is a flag to enable installing by default into ./.bundle rather than to GEM_HOME. Needs agreement that this is still a good idea in 2025, and whether ./.bundle is the best choice or we should use another default, like vendor/bundle.

[duckinator]

I've been using BUNDLE_PATH: ".bundle/gems" since at least 2017, and it's worked wonderfully.

@indirect haven't you been using a similar config?

[indirect]

Yes, I've been using bundle config set --global path .bundle since about 2014. The downside is that you have to re-install gems once for every application, the upside is that individual applications can't interfere with each other's gems.

[duckinator]

My understanding is the cache is shared, so it'd be re-installing, but not re-downloading. Is that correct?

[indirect]

I believe we shipped the shared cache in 2019 or so, so that is my understanding as well, yes.

[hsbt]

I'm against this with default. I don't want to build non-binary gem like ed25519 each project.

[deivid-rodriguez]

I'm pretty sure those were the pros and the cons when this change was initially proposed (more disk space and install time,vs more independence), and it seems they still are.

Bundler 4 should also be introducing a shared cache through #8658, so I wonder if this change in defaults should be delayed to a later major, once the shared cache is a stable default so the drawbacks are less relevant.

Note that the shared cache involves both gem downloads and extension compilation so aims at fixing both issues (download time/space and extension re-building).

[ascarter]

I think it is entirely relevant in 2025. The trend is to use isolated build environments (devcontainers or Fedora Toolbox for example). Bundler's default behavior of user level global seems wrong these days. Other systems like Cargo, uv for Python, or NPM default to isolated local environments. The shared cache you mentioned does alleviate a lot of the practical issues. I think .bundle is a good default. To me, vendor is reserved for gems I want to explicitly put into my source control tree (i.e. I'm preserving a specific revision but maybe not a full fork). I'd rather have a very simple rule for what can be .gitignore'd.

I also think that having you opt into global explicitly makes more sense than having to opt out all the time for every project in order to keep it local. You could then run the exact same bundler commands and just add --global when you want to share at your user level. I think system level global makes no sense in any cases.

[simi]

the upside is that individual applications can't interfere with each other's gems.

What does it mean? What's the risk with shared gems?

[deivid-rodriguez]

For now I'll be shipping Bundler 2.7.0 with both local installation by default and the improvements to cache gems and extension compilations. So the mentioned drawbacks are not actually a problem.

There's a known issue with the global cache but I hope to fix it in time for Bundler 4.

[voxik]

I am against. There is no reason to not share the gems among applications. And this in general would make life harder to distributions such as Fedora, because it would promote pattern which goes against their goal to share more and limit duplication.

And I am against .bundle or whatever path which starts by . which might be treated as a hidden directory. There is no reason to hide such directory.