Issue #19972 has been updated by rubyFeedback (robert heiler).
I also like the overall idea - aka to have more fine-tuned
control. While I don't run into the same issues described as
vo.x, I do have to work in restricted areas every now and
then; university campus sites are a good example, where I
tend to have a Linux system with mostly just my home directory
available. These tend to have outdated ruby installations.
I get around that issue by simply changing $PATH and using
a self-compiled ruby in my $HOME directory then. But sometimes
it is a bit confusing since you end up with multiple different
ruby versions and gem versions as well.
I also think that we have arrived to this situation
by
evolution, not by design.
I think so too. Lateron changes sometimes invalidate or simplify
prior assumptions made. See bundler's integration into rubygems;
before that I remember drbrain/dblack (I forgot the nick right now)
pointing that out how they use partially overlapping functionality
(before the merge; and I am still not sure if the merge is totally
complete now. I am mostly using gems, so I have no idea about
bundler).
I have not thought about whether the proposal he made comes with
disadvantages or trade-off, but the general idea to allow for more
fine-tuned control may be useful.
BTW I have reported it here, because I think that
RubyGems
provides all it is needed. So it is not RubyGems ticket
after all.
I think it is ok to suggest it on MRI here because it also asks the
ruby core devs about real world usage of gems (and problems). Again,
I have no idea whether the proposed suggestion solves this issue or
not, but I personally can relate to some of the issues pointed out.
The current way can be confusing, also because as in the example
provided, you don't easily know where ruby finds stuff in such
dual-ruby setups in a restricted setting. A user may install gems
via --user-install but perhaps due to some odd situation may pick
up other gems from another directory. For instance, when I install
jruby, it also uses the same directory that I used for my self-compiled
MRI on my home system; then it reports that ruby-gtk3 related gems
need to be recompiled, but these were installed by MRI ruby (and
don't work on jruby anyway). So this is also confusing to me, and
perhaps to other ruby users too (if they have a comparable use case).
I am looking at this problematic mainly from Fedora
POV, where we
manage these directories via RPM and we want to manage these
directories via RPM only as much as possible. StdLib certainly.
And it should be different place from the other RPM managed gems
IMHO
I think debian has had similar issues in the past too. So that's
relatable. GoboLinux (and NixOS) even managed versioned directories
for all applications installed. So one would have e. g. /Programs/Ruby/2.2.0/,
/Programs/Ruby/3.2.1/ and so forth. Managing subdirectories makes sense
as well. I guess the biggest question I have is how users can query
all of this easily.
The single most used command I tend to have for gem, aside from "gem install
foobar", is "gem env". Should this show additional information? For
instance,
it could report which gems are installed where, via some new flag or so,
e. g. "gem env extended" or "gem env full" or whatever else fits.
This probably needs a few iteration steps until it works well. Perhaps vit
can suggest some proposed steps, including which methods should work.
We have Gem.default_dir right now but not Gem.bundled_gems_dir (and I am
not sure about the API there, perhaps the name should be different; I can't
think of a better name right now though).
----------------------------------------
Feature #19972: Install default/bundled gems into dedicated directories
https://bugs.ruby-lang.org/issues/19972#change-105100
* 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/