Definitive method for managing ruby installations

  • Thread starter Carl Youngblood
  • Start date
C

Carl Youngblood

It seems like most ruby programmers build and install ruby from
source. At least that is what I gather from previous comments made on
the list. I'm wondering what the best way of keeping one's ruby
installation up-to-date is, considering that with each new stable
release one would have to reinstall all add-ons. Granted, the new
package management utilities like rpa and gems seem to have alleviated
this problem somewhat, but it still seems like there should be a more
automated way to upgrade one's installation without having to remember
everything that was installed before. What do you guys do?

Thanks,
Carl
 
T

trans. (T. Onoma)

On Saturday 09 October 2004 12:54 am, Carl Youngblood wrote:
| It seems like most ruby programmers build and install ruby from
| source. At least that is what I gather from previous comments made on
| the list. I'm wondering what the best way of keeping one's ruby
| installation up-to-date is, considering that with each new stable
| release one would have to reinstall all add-ons. Granted, the new
| package management utilities like rpa and gems seem to have alleviated
| this problem somewhat, but it still seems like there should be a more
| automated way to upgrade one's installation without having to remember
| everything that was installed before. What do you guys do?
|
| Thanks,
| Carl

Might Ruby itself be a Gem one day?

T.
 
M

Mathieu Blondel

release one would have to reinstall all add-ons. Granted, the new
package management utilities like rpa and gems seem to have alleviated
this problem somewhat, but it still seems like there should be a more
automated way to upgrade one's installation without having to remember
everything that was installed before.

I have a question about rpa-base and gems. What's the difference between
the two ? Can't there exist conflicts if we use the two ?

Thanks,
MB
 
C

Chad Fowler

I have a question about rpa-base and gems. What's the difference between
the two ? Can't there exist conflicts if we use the two ?

There are a lot of differences between the two under the covers, but
they attempt to essentially do the same thing. You can find more of a
discussion in the ruby-talk archives.

They can coexist peacefully.

Chad
 
J

James Edward Gray II

They can coexist peacefully.

Just curious. I think I read in the Pickaxe II that RubyGems uses
library stubs by default now? (Please, correct me if I'm wrong.)
Would you need to shut this behavior off if you use both, to keep it
from clobbering an RPA installed library?

James Edward Gray II
 
D

Dick Davies

* James Edward Gray II said:
Just curious. I think I read in the Pickaxe II that RubyGems uses
library stubs by default now? (Please, correct me if I'm wrong.)
Would you need to shut this behavior off if you use both, to keep it
from clobbering an RPA installed library?

Last I heard that had been taken out again, largely for that reason.
 
J

Jim Weirich

James said:
Just curious. I think I read in the Pickaxe II that RubyGems uses
library stubs by default now? (Please, correct me if I'm wrong.) Would
you need to shut this behavior off if you use both, to keep it from
clobbering an RPA installed library?

RubyGems 0.8.0 and later do not use library stubs. They were abandoned
because they prevented gems from managing multiple simultaneous versions
of a library.

However, if you install the *same* library with both RPA and Gems, it's
a toss up one which one will actually be chosen at runtime.
 
M

Mauricio Fernández

RubyGems 0.8.0 and later do not use library stubs. They were abandoned
because they prevented gems from managing multiple simultaneous versions
of a library.

AFAIK RubyGems pre-0.8.0 could manage simultaneous versions fine.
I believed that the main problem with library stubs was... the stubs
themselves, because they were essentially unmanaged and could be
overwritten when installing manually etc (rpa-base never overwrites
anything it doesn't own unless told to).
However, if you install the *same* library with both RPA and Gems, it's
a toss up one which one will actually be chosen at runtime.

The RubyGems version will always be chosen if the "require hack"
(-rubygems or RUBYOPT=rubygems) is in place, if I have understood the
code correctly.
 
J

Jim Weirich

Mauricio said:
AFAIK RubyGems pre-0.8.0 could manage simultaneous versions fine.

Right. Prevented was too strong. But they didn't interact well with
RubyGems multiversion support. So they are gone.
I believed that the main problem with library stubs was... the stubs
themselves, because they were essentially unmanaged and could be
overwritten when installing manually etc (rpa-base never overwrites
anything it doesn't own unless told to).


The RubyGems version will always be chosen if the "require hack"
(-rubygems or RUBYOPT=rubygems) is in place, if I have understood the
code correctly.

And if they don't load rubygems, then the RPA version would be used.
Hence, it's a toss-up (not a random one, but one relaying on information
I didn't have ... sorry, should have been more specific).
 
C

(Curne) Simon Conrad-Armes

It seems like most ruby programmers build and install ruby from
source. At least that is what I gather from previous comments made on
the list. I'm wondering what the best way of keeping one's ruby
installation up-to-date is, considering that with each new stable
release one would have to reinstall all add-ons. Granted, the new
package management utilities like rpa and gems seem to have alleviated
this problem somewhat, but it still seems like there should be a more
automated way to upgrade one's installation without having to remember
everything that was installed before. What do you guys do?

Thanks,
Carl

Sitting on an OS X box (darwin), I make a package from source of
ruby-1.8.2-preview2 as a staged install. Everything else I install as
gems or direct install. I wish everything was gems, but sometimes I
have to nitpick the files out when I want to remove them. A bit of a
mess but my best option in lack of ruby pkgsys unification.

/Curne
 
E

Eric Schwartz

Carl Youngblood said:
It seems like most ruby programmers build and install ruby from
source.

I use the pre-packaged debs. Saves time and worry on my part.

-=Eric
 
C

Charles Hixson

Eric said:
I use the pre-packaged debs. Saves time and worry on my part.

-=Eric
I use the pre-packaged debs too, but when they get stale, I like to
compile a different version of Ruby into /usr/local, at which point the
rpa & ruby-gems become QUITE valuable. (That's how I finally got fxruby
installed, when fxscintilla wouldn't. And it made Sqlite much easier!)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top