Issue #19972 has been updated by vo.x (Vit Ondruch). Dan0042 (Daniel DeLorme) wrote in #note-5:
I'm not against the idea, but there's already quite few a directories for ruby libraries and TBH it's getting a bit confusing.
lib/ruby/3.2.0 lib/ruby/gems/3.2.0 lib/ruby/site_ruby/3.2.0/x86_64-linux lib/ruby/vendor_ruby/3.2.0/x86_64-linux
These are for Ruby *libraries* as you say. Not for gems. On Fedora, we are occasionally using the vendor dir for our packages, but we prefer the gemified versions of libraries, no matter if RPM managed or `gem install`ed. For gems, the paths are ~~~ $ gem env ... snip ... - GEM PATHS: - /usr/local/lib/ruby/gems/3.3.0+0 - /builddir/.local/share/gem/ruby/3.3.0+0 ... snip ... ~~~ Although RubyGems know `vendor` dir, which is not even listed by `gem env`.
lib/ruby/default_gems/3.2.0 **new!!!**
Yep, something like this would be listed among the `GEM PATHS` by the command above. Plus also `bundled_gems` dir.
from https://stdgems.org/
* Default gems: These gems are part of Ruby and you can always require them directly. You cannot remove them. They are maintained by Ruby core. * Bundled gems: The behavior of bundled gems is similar to normal gems, but they get automatically installed when you install Ruby. They can be uninstalled and they are maintained outside of Ruby core.
I don't think that https://stdgems.org/ is relevant here, because it is 3rd party site. The proper documentation is here: https://github.com/ruby/ruby/blob/14bf7164a69944b4e54aa2502cb5749d700505e5/d... https://github.com/ruby/ruby/blob/14bf7164a69944b4e54aa2502cb5749d700505e5/d... And there are differencies such as: "They can be uninstalled" vs "They can be uninstallable from Ruby installation."
According to the above, bundled gems are closer in behavior to user gems than to default gems; does it really make sense to mix bundled+default?
My proposal is to install them into separate directories. But maybe the remark was not directed to me :)
From my reading of the situation, it seems like there should be 1. a directory for default gems 2. the regular "gems" directory for bundled gems and root-installed gems 3. Gem.user_dir for user-installed gems
My proposal is to make this flexible enough to allow the situation as you describe, while I'd prefer: 1. a directory for default gems 2. a directory for bundled gems 3. directory for system wide installed gems 4. dir for user installed gems Please note that I deliberately not using terms such as "root-installed gems" or "Gem.user_dir for user-installed gems" to prevent too much implications. And if you look at my POC, it actually does not change anything in RubyGems, it just merely changes configuration. ---------------------------------------- Feature #19972: Install default/bundled gems into dedicated directories https://bugs.ruby-lang.org/issues/19972#change-105197 * Author: vo.x (Vit Ondruch) * Status: Open * Priority: Normal ---------------------------------------- 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/