Project

General

Profile

Actions

Feature #5617

open

Allow install RubyGems into dediceted directory

Added by vo.x (Vit Ondruch) over 12 years ago. Updated almost 6 years ago.

Status:
Assigned
Target version:
-
[ruby-core:40941]

Description

Hello,

I would like to propose my patch, which allows to optionally install RubyGems library into dedicated directory, out of the default Ruby directory structure. This should enable to easily share one RubyGems library by more Ruby implementations and avoids code duplication. I did this patch since Fedora prohibits duplication of system libraries [1], which would be the case if MRI and JRuby are installed in parallel.

Thank you for considering this patch.

Vit

[1] https://fedoraproject.org/wiki/Packaging:Guidelines#Duplication_of_system_libraries


Files


Related issues 1 (1 open0 closed)

Related to Ruby master - Feature #19972: Install default/bundled gems into dedicated directoriesAssignedhsbt (Hiroshi SHIBATA)Actions

Updated by kosaki (Motohiro KOSAKI) about 12 years ago

  • Status changed from Open to Rejected

% autoconf
/usr/bin/gm4:configure.in:2826: Warning: too few arguments to builtin `patsubst'
autom4te: /usr/bin/gm4 failed with exit status: 1

You have to run your patch BEFORE upload it. :-/

Updated by vo.x (Vit Ondruch) about 12 years ago

To be precise, the github patch is fixed version of 0001-Allow-to-install-RubyGems-into-custom-location-outsi.patch. The 0002-Avoid-duplication-of-datadir.rb-which-belongs-to-Rub.patch still needs to be applied. I'll upload correct version of the 0001 tomorrow, since I'm working on different computer now.

Please reopen the issue.

Updated by Eregon (Benoit Daloze) about 12 years ago

Hello,

I would be very interested to have a way to tell RubyGems to install at a particular shared path by default (to avoid unnecessary duplication), but only for the gems which are not implementation-dependents (e.g.: C extension should be installed in an unshared path of course).

I think this should be done in RubyGems's code, instead of an option in the configuration process (it would also avoid to do the work for each implementation).

What do you think?

P.S.: The duplication is especially bad since it means I must install all my (n) dependencies on every implementation/version when I want to test on them, which means m*n gem install (or fetching the repository) which could just be n if the gems contain only implementation-independent code.

Updated by vo.x (Vit Ondruch) about 12 years ago

Benoit Daloze wrote:

Hello,

I would be very interested to have a way to tell RubyGems to install at a particular shared path by default (to avoid unnecessary duplication), but only for the gems which are not implementation-dependents (e.g.: C extension should be installed in an unshared path of course).

I think this should be done in RubyGems's code, instead of an option in the configuration process (it would also avoid to do the work for each implementation).

What do you think?

Actually this two patches are just subset of patches I'd like to introduce into Fedora. You can find all the patches in my repository [1]. Some of them, like this one, are more Ruby specific, others are RubyGems specific [2].

If you go through this patch, you'll see that this patch is definitely Ruby specific. It allows to install RubyGems into dedicated directory (specifiable by configuration parameter) and extends Ruby's search path to include this path.

There might be also required patch to RubyGems's setup.rb to allow to install updated RubyGems into this location, but first, I'd like to see this feature accepted.

Please note that this feature is just optional and it keeps the current Ruby+RubyGems behavior intact unless requested.

[1] https://github.com/voxik/ruby.spec/
[2] https://github.com/rubygems/rubygems/issues/210

Updated by kosaki (Motohiro KOSAKI) about 12 years ago

I think this should be done in RubyGems's code, instead of an option in the configuration process (it would also avoid to do the work for each implementation).

What do you think?

Actually this two patches are just subset of patches I'd like to introduce into Fedora. You can find all the patches in my repository [1]. Some of them, like this one, are more Ruby specific, others are RubyGems specific [2].

If you go through this patch, you'll see that this patch is definitely Ruby specific. It allows to install RubyGems into dedicated directory (specifiable by configuration parameter) and extends Ruby's search path to include this path.

There might be also required patch to RubyGems's setup.rb to allow to install updated RubyGems into this location, but first, I'd like to see this feature accepted.

Please note that this feature is just optional and it keeps the current Ruby+RubyGems behavior intact unless requested.

What's happen if a user install non-rpm gems? If it's installed into
fedora's "dedicated directory", some ruby interpreter may access it
and makes SEGV.

Updated by vo.x (Vit Ondruch) about 12 years ago

Motohiro KOSAKI wrote:

What's happen if a user install non-rpm gems? If it's installed into
fedora's "dedicated directory", some ruby interpreter may access it
and makes SEGV.

I am not sure I understand your point, but I'll try to elaborate a bit. With this patch there are two scenarios:

  1. The default is that everything works as it worked now. I.e. you download the Ruby tarball, you don't care about any configuration options, everything is installed in default including RubyGems under Ruby directory.

  2. You are user who cares about duplication of system libraries or you may be like to share gems between two interpreters (with all the consequences), therefore there is this configuration option "--with-rubygemsdir" if user likes.

I see no chances that "random ruby interpreter may access some inappropriate gem and SEGV" unless the user explicitly wants.

If you are using RPM managed gems (but also other software), it gets installed into /usr. If you like to install your own software from tarball, it should go into /usr/local. Again, I see no chance to collide unless you explicitly want.

The main reason for Fedora for this switch is to avoid duplication of system libraries, e.g. to allow MRI and JRuby to share the RubyGems library itself. This switch is one step forward to achieve this goal.

Updated by kosaki (Motohiro KOSAKI) about 12 years ago

I meant,

  • the user use "--with-rubygemsdir" ruby binaries, and
  • use unpatch gems

Why the gems should go into /usr/local? Who care?

Updated by vo.x (Vit Ondruch) about 12 years ago

Motohiro KOSAKI wrote:

% autoconf
/usr/bin/gm4:configure.in:2826: Warning: too few arguments to builtin `patsubst'
autom4te: /usr/bin/gm4 failed with exit status: 1

You have to run your patch BEFORE upload it. :-/

0003-Removed-superfluous-bracket.patch fixes the issue.

Updated by vo.x (Vit Ondruch) about 12 years ago

Motohiro KOSAKI wrote:

I meant,

  • the user use "--with-rubygemsdir" ruby binaries, and
  • use unpatch gems

RubyGems library is in charge where to install your gems. Here [1] is the logic and I am not touching it in this patch. That means only RubyGems library is installed into the custom location while the gems are installed into location specified by RubyGems.

Why the gems should go into /usr/local? Who care?

It is good habit to place right content into right folders. You probably don't save your documents into /etc or /tmp just because you can. There are standards [2] which describes what should be placed where. It is definitely good idea to not intermix software installed by RPM and by you manually. Therefore there are different locations for that purposes.

Speaking as a Ruby maintainer of Fedora, it is definitely my responsibility to cultivate good habits and place software where it belongs. I understand that Ruby supports more OSes with different needs and different standards, therefore my patch does not change any defaults, but allow to support needs of my platform. Btw I am using Ruby also on Windows and there is definitely no need for such configuration option, but it definitely does not harm anybody.

[1] https://github.com/rubygems/rubygems/blob/master/lib/rubygems/defaults.rb#L21-44
[2] http://www.pathname.com/fhs/pub/fhs-2.3.html

Updated by naruse (Yui NARUSE) about 12 years ago

  • Status changed from Rejected to Assigned
  • Assignee set to drbrain (Eric Hodel)
  • Show standalone patch; a patch to previous patch is difficult to inspect
  • How will users use gems with this patched ruby?

Updated by vo.x (Vit Ondruch) about 12 years ago

Yui NARUSE wrote:

  • Show standalone patch; a patch to previous patch is difficult to inspect

Here is the squashed version.

  • How will users use gems with this patched ruby?

There is no difference at all IMO.

Updated by drbrain (Eric Hodel) almost 12 years ago

This functionality is fine with me, but since it applies to the build system and not RubyGems I think matz or someone else should decide if it should be applied.

I had to manually apply one chunk of this patch, so I attached an updated version.

Updated by nobu (Nobuyoshi Nakada) almost 12 years ago

  • AC_DEFINE_UNQUOTED(RUBYGEMS_DIR,"$rubygemsdir")

Updated by nobu (Nobuyoshi Nakada) almost 12 years ago

=begin
Add !! mark

  • AC_DEFINE_UNQUOTED(RUBYGEMS_DIR,"$rubygemsdir")
    =end

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

Ping. Any possibility to accept this patch please?

Updated by mame (Yusuke Endoh) over 11 years ago

  • Target version set to 2.6
Actions #21

Updated by naruse (Yui NARUSE) about 6 years ago

  • Target version deleted (2.6)

Updated by mame (Yusuke Endoh) almost 6 years ago

  • Assignee changed from matz (Yukihiro Matsumoto) to hsbt (Hiroshi SHIBATA)
Actions #23

Updated by hsbt (Hiroshi SHIBATA) 3 months ago

  • Related to Feature #19972: Install default/bundled gems into dedicated directories added
Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0