[Rubygems-developers] Can anyone shed a little light on executable gems for me?

michael greenly mgreenly at gmail.com
Sat Dec 29 14:23:18 EST 2007

Sure, I think your setup is typical (not sharing a single bin directory) but
it's one of the components that's more or less essential to support the
linux file hierarchy standards.  Linux distributions typically handle this
by using --program-suffix and then creating a dummy package that symlinks
with the base name to the suffixed name.

I'm not suggesting I'd want anything like that for Gems but I wanted to look
at was being able to control where the executable scripts were put for gem
installs and making this a ./configure time option.

That combined with a 'gem run' command would be all that's needed at the
moment to clean up the multiple installs from source issue.  In my case it
would give me 'gem1.8 run rails' or 'gem1.9 run rails'.  It should be a
rather straight forward hacking of 'gem where'.

It's just a thought I want to explore

On Dec 29, 2007 12:05 PM, Stephen Bannasch <stephen.bannasch at deanbrook.org>

>  I'm not sure how to make clean and simple.
> One difference between my setup and yours is that I have just one ruby in
> /usr/local (1.8.6p111) and mine is actually installed there. My other two
> major ruby environments (jruby and 1.9) always live in separate
> directories with no links from /usr/local.

I think a 'gem run' command would fix having to mess with paths...

> An element that both simplifies and complicates is that I modify PATH to
> put a path to <other_ruby>/bin first when I want to work in JRuby or 1.9.
> That allows me to use gem, rake, rails or any other command that might get
> installed in bin and it always works. It also means I've got to keep track
> of the shells I've modified path in. I almost never use full paths to
> execute anything.

I've been following these issues for quite a while and have recently decided
it was time to dig into the code so I could get a better understanding of
the real problems.  Although I think for the most part they are political
not technical.

> If you haven't seen it check out this thread on ruby-core to get an idea
> of some of the issues mixing package-based ruby with locally-installed
> additions:
>   http://blade.nagaokaut.ac.jp/cgi-bin/vframe.rb/ruby/ruby-core/12825?1
> 2676-13118

Michael Greenly
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rubygems-developers/attachments/20071229/9582a189/attachment.html 

More information about the Rubygems-developers mailing list