Feature #14737


Split default gems into separate directory structure

Added by vo.x (Vit Ondruch) over 4 years ago. Updated over 2 years ago.

Target version:


On Fedora, we are using operating_system.rb 1, 2 to setup various RubyGems paths. Unfortunately, if we change Gem.default_dir (which we want to point into user home directory on Fedora), then this also changes location for default gems (!!), which are later not discovered by RubyGems 3. It was not been a big deal for use, since we used to unbundle the gems shipped in Ruby, but with the gemification of StdLib, unbundlig becomes unsustainable (it is more work, but mainly it is incompatible change).

To fix this issue, I modified the operating_system.rb to behave similarly to what Arch does 4, i.e. we started to inject "--user-install" option 1. Unfortunately, this revealed the RubyGems are not respecting their own interfaces and I had to fix at least one of them along the way to make it work 6. Apparently, using the "--user-install" option itself has some drawbacks and what is worse, it is not respected by Bundler, which was recently pointed out 5.

When I was fixing RubyGems 6, I just realized how the default gems are hacked up and how much is the original RubyGems configurability broken by this. This leads me to the proposal: Could we please install default gems into different directory then the other, user installed, gems? Since RubyGems were always designed to support various gem directory structures, the directory structure for default gems would become just other directory directory structure and would not collide with overrides in operating_system.rb, letting the distributions to override what was always designed to be overridable.

BTW I believe that one nice side effect of this change would be simplification of RubyGems code base. The default gems would live in "default_gems" directory, their .gemspec files could be in standard "default_gems/specifications" directory and we could forget about "default_gems/specifications/defaults", etc.

BTW2 I could fill this against RubyGems, but the default gems are Ruby stuff IMO, so I think this is appropriate tracker.

Updated by shevegen (Robert A. Heiler) over 4 years ago

BTW2 I could fill this against RubyGems, but the default gems
are Ruby stuff IMO, so I think this is appropriate tracker.

It may be a chicken-egg problem, e. g. where to start.

I think it may take a little while altogether; bundler integration;
using gems for distributed ruby add-ons. The actual change towards
that will take a little while. See how bundler integration had to
be delayed after Hiroshi Shibata encountered problems.

To Arch using --user-install - I am not sure this would be the
recommended or assumed way. I myself use --user-install when I am
in a restricted environment (such as having a user account on a
university *nix system). At home I use prefixes such as
/Programs/Ruby/VERSION_HERE to install gems. Most people I guess
may use /usr/ or /usr/local/ as prefix, which understandably
creatres more problems for them. I also have to agree in general
that the directory structure of rubygems used is not very ...
intuitive. I always wondered about that, but I guess it is
difficult to change without momentum or "sufficient need".

Perhaps it may actually be better to get a discussion going on
the rubygems tracker; in particular get some of the people who
have been working with gem code for a long time, such as
drbrain, to see whether (after all the gemification and
bundler-integration is done) the whole ordeal can be simplified
or changed. For instance, I am not even sure that you MUST
have separate directory structures. You could keep track of
the information in a file too, or?

Updated by hsbt (Hiroshi SHIBATA) over 4 years ago

  • Status changed from Open to Assigned
  • Assignee set to hsbt (Hiroshi SHIBATA)

Updated by vo.x (Vit Ondruch) over 3 years ago

I opened PR 1 implementing this.

Actions #4

Updated by jeremyevans0 (Jeremy Evans) over 2 years ago

  • Tracker changed from Bug to Feature
  • ruby -v deleted (ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-linux])
  • Backport deleted (2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN)

Also available in: Atom PDF