Feature #5617

Allow install RubyGems into dediceted directory

Added by Vit Ondruch over 2 years ago. Updated 7 months ago.

[ruby-core:40941]
Status:Assigned
Priority:Normal
Assignee:Yukihiro Matsumoto
Category:build
Target version:next minor

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

0001-Allow-to-install-RubyGems-into-custom-location-outsi.patch Magnifier (3.3 KB) Vit Ondruch, 11/11/2011 10:12 PM

0002-Avoid-duplication-of-datadir.rb-which-belongs-to-Rub.patch Magnifier (878 Bytes) Vit Ondruch, 01/11/2012 12:42 AM

0003-Removed-superfluous-bracket.patch Magnifier (846 Bytes) Vit Ondruch, 01/11/2012 06:02 PM

Allow-to-install-RubyGems-into-custom-location-outsi.patch Magnifier (3.31 KB) Vit Ondruch, 01/12/2012 07:01 PM

custom_rubygems_location.patch Magnifier - Updated patch to deal with bit rot (3.01 KB) Eric Hodel, 06/02/2012 08:38 AM

20120606-Allow-to-install-RubyGems-into-custom-location-outsi.patch Magnifier - Patch with !<verconf>! (3.32 KB) Vit Ondruch, 06/06/2012 09:18 PM

History

#1 Updated by Vit Ondruch over 2 years ago

Remove duplicated datadir.rb

#2 Updated by Motohiro KOSAKI over 2 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. :-/

#3 Updated by Vit Ondruch over 2 years ago

Actually I ran the patch. The updated version is available here: https://github.com/voxik/ruby.spec/blob/master/ruby-1.9.3-custom-rubygems-location.patch

#4 Updated by Vit Ondruch over 2 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.

#5 Updated by Benoit Daloze over 2 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.

#6 Updated by Vit Ondruch over 2 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

#7 Updated by Motohiro KOSAKI over 2 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.

#8 Updated by Vit Ondruch over 2 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.

#9 Updated by Motohiro KOSAKI over 2 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?

#10 Updated by Vit Ondruch over 2 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.

#11 Updated by Vit Ondruch over 2 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

#12 Updated by Yui NARUSE over 2 years ago

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

#13 Updated by Vit Ondruch over 2 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.

#14 Updated by Eric Hodel almost 2 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.

#15 Updated by Nobuyoshi Nakada almost 2 years ago

  • ACDEFINEUNQUOTED(RUBYGEMS_DIR,"$rubygemsdir")

#16 Updated by Nobuyoshi Nakada almost 2 years ago

=begin
Add !! mark
+ ACDEFINEUNQUOTED(RUBYGEMS_DIR,"$rubygemsdir")
=end

#17 Updated by Vit Ondruch almost 2 years ago

I am attaching updated patch with added !!

#18 Updated by Vit Ondruch over 1 year ago

Ping. Any possibility to accept this patch please?

#19 Updated by Yusuke Endoh over 1 year ago

  • Target version set to next minor

Also available in: Atom PDF