[arch-general] [arch-dev-public] Ruby directory clean up proposal.

Thomas Dziedzic gostrc at gmail.com
Tue Feb 14 11:46:34 EST 2012


On Tue, Feb 14, 2012 at 3:04 AM, Peter Lewis <plewis at aur.archlinux.org> wrote:
> On Monday 13 Feb 2012 20:47:01 Thomas Dziedzic wrote:
>> >> /etc/gemrc - contains "gem: --user-install" to install user installed
>> >> gems with gem to $HOME/.gem/gems
>> >
>> > I didn't know about --user-install, but I just set GEM_HOME (actually, I
>> > use RVM). Can what you want be done by globally setting GEM_HOME to be
>> > based off of $HOME? Or is --user-install the preferred way?
>>
>> I did look into $GEM_HOME but I thought this was inadequate since
>> running sudo gem install foo would still install foo to the
>> system-wide gem directory. Having --user-install in /etc/gemrc forces
>> it to install to /root/.gem/gems instead.
>
> Great, I should have read up on --user-install then. Sounds great.
>
>
>> > And as much as I have to admit that I'd really like to be able to install
>> > gems system-wide and use their built-in dependency management, bundler
>> > etc... I think that road probably leads to madness and death, especially
>> > when many popular gems will still be managed by pacman (and rightly so).
>> > So, I would be careful about doing this, and would suggest that we go for
>> > only letting 'gem' install things under $HOME. Anything that should go
>> > system-wide should have a PKGBUILD.
>>
>> Right, by default I want it so that you wont be able to install system
>> wide gems with gem.
>> But I can't stop users removing --user-install from the gemrc file and
>> installing to the system-wide directories.
>
> Perhaps we have an argument for proposing an option like --user-install that
> doesn't allow users to disable it then.
>

I think just making --user-install the default will be fine.
I don't want to stop people from doing this completely since there
will always be around it.

>
>> I have another plan brewing in regard to letting users separately
>> install pacman installed gems and gem installed gems to the
>> system-wide directory.
>> I wont do it in this cleanup iteration, but next cleanup, I will add a
>> /var/lib/gems or /var/lib/ruby/gems folder specifically so that when
>> running sudo gem install without --user-install, it will install to
>> /var/lib/.. and gems installed via pacman will install to
>> /usr/lib/ruby/gems. This will cleanly seperate pacman installed ruby
>> gems to /usr and sudo-gem without --user-install installed gems to
>> /var. This will bring ruby and rubygems into fhs compliance, at least
>> afaik :)
>
> Nice. Just out of interest, what RUBYLIB order precedence would you use, to
> deal with the case when some similar things (say different versions of the
> same gem) were installed in /usr/lib/ruby and /var/lib/gems at the same time?
>

The order will be $HOME/.gem/ruby, /var/lib/gems, /usr/lib/ruby/gems
Just to reiterate, the var path will be for system wide gems installed with gem.
The usr path will be for gems installed with a PKGBUILD.
Upstream seems to be fine with this order also.

>
>> Doing this will require modifying the GEM_PATH and all PKGBUILDs that
>> install ruby gems. This wont break the PKGBUILDs just make them
>> uncompliant with our standards, instead it will just install to /var
>> if you don't change them which will be in GEM_PATH. BTW, GEM_PATH is
>> the location where rubygems searchs for gems.
>>
>> I have already talked with upstream rubygems devs and they seem to
>> agree that this is a good plan :)
>
>> I'm certain I will go with 1 this cleanup and will implement the above
>> on the next cleanup.
>
> All great.
>
>
>> > Of course, suggesting RVM for user-installed gems(ets) is probably also a
>> > good idea.
>>
>> For rails development, I can't recommend rvm enough, you can manage
>> multiple gemsets with multiple ruby versions, and have it
>> automatically load project specific .rvmrc files when you cd into
>> those directories.
>> This is probably one of the nicest language management tools for a
>> programming language I have encountered so I would recommend it :)
>
>> Ofc, rvm might be overkill if you're just doing development on small
>> projects, or if you just don't need a clean separation of multiple
>> ruby environments.
>
> Agreed. It really is a breeze to use. I don't do much rails, but just use
> clean gemsets along with bundler, most of the time. It helps with predicting
> what's going to happen when I want to run the code on another machine.
>
>
>
>> > PS. A while ago I was getting very frustrated that the version of rubygems
>> > bundled with ruby itself was so out-of-date so quickly, but 'gem update
>> >  --system' is a very bad idea in combination with pacman. So, I spent a
>> > while hacking together this package, which installs the latest version of
>> > rubygems itself alongside ruby, system-wide:
>> >
>> > https://aur.archlinux.org/packages.php?ID=50346
>> >
>> > It's hacky, but it works :-) I wish there was a cleaner way.
>>
>> I was also thinking about this, and I might split rubygems off into a
>> seperate package and have ruby optdepend or depend on it so I can
>> update the package separately from ruby.
>
> Hell yeah. Please do. I assume you're aware of this:
>
> https://bugs.archlinux.org/task/17611
>

I wasn't aware of this bug report, but I was aware of the recently
added configure flag:
--disable-rubygems      disable rubygems by default

> Pete.


More information about the arch-general mailing list