Hot Take: bundler should install all gems into ~/.bundle/cache/ or ~/.cache/bundler/, not the $GEM_HOME or rubygems' gem root directory.

If I'm working on a Rails app (or two, or more), and in the Gemfile it requires a gem called 'florb' and it also has an executable called 'florb', why would I want that installed globally such that hitting fl<TAB> in the terminal displays 'florb' as one of the tab completion options, even when I'm outside of the app? App deps should not pollute your gems.

@postmodern

Yup. This situation was my first motivator to start using direnv.

@robbkidd I globally configure bundler to always use `./vendor/bundle`, although that may lead to a lot of wasted disk space and duplicate installs of `rake`, etc.

@postmodern I similarly configure bundler to always use .direnv/ruby and use layout ruby w/direnv so everything matches up nicely.

@postmodern

👍 Disk space is cheap. Mental health lost to being gaslit by dependency conflicts is not.

@robbkidd how would changing the cache directory of Bundler, from $GEM_HOME to another directory, cause dependency conflicts? Bundler is supposed to handle that for you. It shouldn't matter where the gems are installed, as long as Bundler can find them.

@postmodern

Eh. Probably "conflicts" was the wrong phrase. Whatever the "why is florb in my $PATH right now? this project doesn't use florb" confusion gets classified as.

@robbkidd but that's the current behavior of bundler! Because bundler installs gems globally into $GEM_HOME or the Ruby's gem root, all install gem executable commands become global accessible by default. Bundler doesn't actually manage $PATH, so all previously globally installed gems with executables would still be accessible in your project.