Best way to install Ruby 1.9

[Juan Zanos]

I'd like to start using Ruby 1.9 more often. Often I could use the
extra performance. However, I'm still concerned about bugs and
incompatibilities. Is there a practical way to use 1.9 in such a
way that these potential problems are minimized? I mostly use Linux
and OSX, and on rare occasions Windows.

 

[Robert Dober]

I'd like to start using Ruby 1.9 more often. =A0Often I could use the ext= ra
performance. =A0However, I'm still concerned about bugs and incompatibili= ties.
=A0 Is there a practical way to use 1.9 in such a way that these potentia= l
problems are minimized? =A0I mostly use Linux and OSX, and on rare occasi= ons
Windows.

Sure, install JRuby(1) and run it with --1.9 switch . Well if this
is not an option you can do something painful like I did, I installed
1.9.1, 1.8.7 and 1.8.6 into $HOME/opt and have scripts that relink
those directories to $HOME/ruby and put $HOME/ruby/bin into my PATH.
However I have issues with gems and my *only* stable Ruby release is
JRuby. I have aliases to all Ruby tools of JRuby like e.g. jgems,
jspec, jri, jirb.... not to get completely confused, which I am
anyway....

(1) Using JRuby will probably give you the extra speed for 1.8.6 too
HTH
Robert


--=20
Si tu veux construire un bateau ...
Ne rassemble pas des hommes pour aller chercher du bois, pr=E9parer des
outils, r=E9partir les t=E2ches, all=E9ger le travail=85 mais enseigne aux
gens la nostalgie de l=92infini de la mer.

If you want to build a ship, don=92t herd people together to collect
wood and don=92t assign them tasks and work, but rather teach them to
long for the endless immensity of the sea.

 

[James Gray]

I'd like to start using Ruby 1.9 more often. Often I could use the
extra performance. However, I'm still concerned about bugs and
incompatibilities. Is there a practical way to use 1.9 in such a
way that these potential problems are minimized? I mostly use Linux
and OSX, and on rare occasions Windows.

One easy way is just to install 1.9 separate from your 1.8 install.
You can do that by feeding the configure script a --program-suffix=19
option which would add a 19 to the end of all the executables it
installs. Thus you would use ruby19, irb19, etc.

Hope that helps.

James Edward Gray II

 

[Robert Dober]

ows.

One easy way is just to install 1.9 separate from your 1.8 install. =A0Yo= u can
do that by feeding the configure script a --program-suffix=3D19 option wh= ich
would add a 19 to the end of all the executables it installs. =A0Thus you
would use ruby19, irb19, etc.

OMG why did I not ask you, or err, reading ./configure --help a little
bit more carefully, before installing!!!!
This avoids probably the kind of compatibility problems I ran into.
Juan, by all means, follow James' approach if you cannot go with
JRuby.
R.

 

[Juan Zanos]

One easy way is just to install 1.9 separate from your 1.8
install. You can do that by feeding the configure script a --
program-suffix=19 option which would add a 19 to the end of all the
executables it installs. Thus you would use ruby19, irb19, etc.

Hope that helps.

James Edward Gray II

I think that's a great way to keep ruby 1.9 separate from 1.8. I'm
still not sure how to manage various versions of 1.9 across various
operating systems.

 

[Juan Zanos]

On Thu, Apr 16, 2009 at 8:32 PM, James Gray

OMG why did I not ask you, or err, reading ./configure --help a little
bit more carefully, before installing!!!!
This avoids probably the kind of compatibility problems I ran into.
Juan, by all means, follow James' approach if you cannot go with
JRuby.
R.

Maybe JRuby is the way to go except when I absolutely have to depend
on interfacing to C. I don't have to worry about OS differences as
much. Also, the way jruby's is distributed is great. I can download
it's entire history and easily and update it easily. It's trivial
to move between different versions, keep them in sync across
different systems, and not worry about screwing everything up.

With ruby1.9 it's a different story. I admire the work that's going
into ruby1.9. I'm just not sure it's going to be so easy to manage.
I could try to deal with whatever versions happen to be in various
package managers. I could maintain a collection of tar balls. I
could maintain directories of different source trees. None of those
seem like very good solutions.

 

[Denis Defreyne]

I'd like to start using Ruby 1.9 more often. Often I could use the
extra performance. However, I'm still concerned about bugs and
incompatibilities. Is there a practical way to use 1.9 in such a
way that these potential problems are minimized? I mostly use Linux
and OSX, and on rare occasions Windows.

I have installed several Ruby versions in the following directories
(using --prefix):

/usr/local/pkgs/ruby-1.8.5-p231
/usr/local/pkgs/ruby-1.8.6-p368
/usr/local/pkgs/ruby-1.8.7-p72
/usr/local/pkgs/ruby-1.9.1-p0

I have /usr/local/pkgs/ruby-current which is a symlink to one of the
above directories. I also have a script that changes the symlink so I
can switch to any version of Ruby at any time. Lastly, I have /usr/
local/pkgs/ruby-current/bin in my $PATH.

--program-suffix is IMHO not a great solution. I prefer keeping the
different Ruby versions entirely separate (no shared gems for
instance). In addition, some applications that use Ruby don't work
well with a Ruby installation that has a custom program suffix
(NetBeans jumps to mind).

Regards,

Denis

 

[Juan Zanos]

I have installed several Ruby versions in the following directories
(using --prefix):

/usr/local/pkgs/ruby-1.8.5-p231
/usr/local/pkgs/ruby-1.8.6-p368
/usr/local/pkgs/ruby-1.8.7-p72
/usr/local/pkgs/ruby-1.9.1-p0

I have /usr/local/pkgs/ruby-current which is a symlink to one of
the above directories. I also have a script that changes the
symlink so I can switch to any version of Ruby at any time. Lastly,
I have /usr/local/pkgs/ruby-current/bin in my $PATH.

--program-suffix is IMHO not a great solution. I prefer keeping the
different Ruby versions entirely separate (no shared gems for
instance). In addition, some applications that use Ruby don't work
well with a Ruby installation that has a custom program suffix
(NetBeans jumps to mind).

Regards,

Denis

I hadn't realized that different gems might not like --program-
suffix. That's good to know. If that's so then the symlink method
seems more robust.

I'm still not sure how I'd maintain those different version
efficiently across different machines. I don't want to introduce
too much maintenance or too much testing perplexity. It seems like
I'd either have to carefully keep track of tarballs (store, backup,
catalog) or do checkouts for each of the separate versions. Every
update of a separate tag is then another download for every machine
and even then it's difficult to be sure that a particular tag hasn't
actually changed.