Issue #19972 has been updated by martinemde (Martin Emde). I like the proposal, and wanted to comment about naming. I know we’ve called them bundled gems for a while and it’s documented that way, but if we solidify this in a directory name it may be confusing for users of bundler. Finding path names in backtraces that show “bundled_gems” for certain gems could be very confusing when they are not related to the bundler bundled gems. If we end up with a separate directory, can we use a name that is unambiguous? `packaged_gems` was the first name that occurred to me but I’ll leave it up to the implementor to decide what’s best. ---------------------------------------- Feature #19972: Install default/bundled gems into dedicated directories https://bugs.ruby-lang.org/issues/19972#change-105396 * Author: vo.x (Vit Ondruch) * Status: Assigned * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- I think that the current situation, where the same directory (lets call it `Gem.default_dir`) is used for default/bundled gems as well as for user installed gems, is suboptimal. During the times, this has caused us quite some issue on Fedora. Historically, we redefined the `Gem.default_dir` to user home directory, to avoid the mixing of system gems and user installed gems. Unfortunately, with advent of default/bundled gems, we were facing issues that these gems were suddenly not listed, etc. I am realizing this issue in full once again since the "user install" RubyGems feature has landed [1]. I also think that we have arrived to this situation by evolution, not by design. Therefore my proposal is: Keep the `Gem.default_dir` for user `gem install`ed gems and lets install default and bundled gems into separate dedicated directories. Have separate `Gem.bundled_gems_dir` and `Gem.default_gems_dir` structures. Of course, if `Gem.default_dir == Gem.bundled_gems_dir == Gem.default_gems_dir`, we still can have the current layout. I have a simple POC here: https://github.com/ruby/ruby/pull/8761 BTW I have reported it here, because I think that RubyGems provides all it is needed. So it is not RubyGems ticket after all. However, I believe that RubyGems could benefit from this long term and some simplifications/cleanups would be possible. [1]: https://github.com/rubygems/rubygems/pull/5327 -- https://bugs.ruby-lang.org/