[ruby-core:124805] [Ruby Feature#14737] Split default gems into separate directory structure

[ruby-core:124805] [Ruby Feature#14737] Split default gems into separate directory structure

[hsbt (Hiroshi SHIBATA) via ruby-core]

Issue #14737 has been updated by hsbt (Hiroshi SHIBATA).

Status changed from Assigned to Rejected

I have no plan to apply this proposal.

I understand that the current situation is not optimal, but there is no advantage to change it considering that this structure has been in use for eight years with no critical issues.

----------------------------------------
Feature #14737: Split default gems into separate directory structure
https://bugs.ruby-lang.org/issues/14737#change-116422

* Author: vo.x (Vit Ondruch)
* Status: Rejected
* Assignee: hsbt (Hiroshi SHIBATA)
----------------------------------------
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.

[1]: https://src.fedoraproject.org/rpms/ruby/blob/master/f/operating_system.rb
[2]: https://src.fedoraproject.org/rpms/ruby/blob/f27/f/operating_system.rb
[3]: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org/message/RZUUKFMNKRB6TGKCQT3FLZYANP5WLEKN/
[4]: https://wiki.archlinux.org/index.php/ruby
[5]: https://bugzilla.redhat.com/show_bug.cgi?id=1574594
[6]: https://github.com/rubygems/rubygems/pull/2116



-- 
https://bugs.ruby-lang.org/
______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/