Definitive method for managing ruby installations

Discussion in 'Ruby' started by Carl Youngblood, Oct 9, 2004.

  1. 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
     
    Carl Youngblood, Oct 9, 2004
    #1
    1. Advertising

  2. 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.
     
    trans. (T. Onoma), Oct 9, 2004
    #2
    1. Advertising


  3. > 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
     
    Mathieu Blondel, Oct 9, 2004
    #3
  4. Carl Youngblood

    Chad Fowler Guest

    On Sat, 9 Oct 2004 17:19:41 +0900, Mathieu Blondel
    <> wrote:
    >
    > > 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 ?
    >


    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
     
    Chad Fowler, Oct 9, 2004
    #4
  5. On Oct 9, 2004, at 5:43 AM, Chad Fowler wrote:

    > 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
     
    James Edward Gray II, Oct 9, 2004
    #5
  6. Carl Youngblood

    Dick Davies Guest

    * James Edward Gray II <> [1024 17:24]:
    > On Oct 9, 2004, at 5:43 AM, Chad Fowler wrote:
    >
    > >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?


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

    --
    Yeah, well I'm gonna build my own lunar space lander! With blackjack aaaaannd Hookers!
    Actually, forget the space lander, and the blackjack. Ahhhh forget the whole thing! - Bender
    Rasputin :: Jack of All Trades - Master of Nuns
     
    Dick Davies, Oct 9, 2004
    #6
  7. Carl Youngblood

    Jim Weirich Guest

    James Edward Gray II wrote:
    > On Oct 9, 2004, at 5:43 AM, Chad Fowler wrote:
    >
    >> 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?


    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.

    --
    -- Jim Weirich http://onestepback.org
    -----------------------------------------------------------------
    "Beware of bugs in the above code; I have only proved it correct,
    not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
     
    Jim Weirich, Oct 9, 2004
    #7
  8. On Sun, Oct 10, 2004 at 05:09:21AM +0900, Jim Weirich wrote:
    > James Edward Gray II wrote:
    > >On Oct 9, 2004, at 5:43 AM, Chad Fowler wrote:
    > >
    > >>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?

    >
    > 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.

    --
    Running Debian GNU/Linux Sid (unstable)
    batsman dot geo at yahoo dot com
     
    Mauricio Fernández, Oct 10, 2004
    #8
  9. Carl Youngblood

    Jim Weirich Guest

    Mauricio Fernández wrote:
    > On Sun, Oct 10, 2004 at 05:09:21AM +0900, Jim Weirich wrote:
    >>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.


    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).
    >
    >>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.


    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).

    --
    -- Jim Weirich http://onestepback.org
    -----------------------------------------------------------------
    "Beware of bugs in the above code; I have only proved it correct,
    not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
     
    Jim Weirich, Oct 10, 2004
    #9
  10. Carl Youngblood

    Aredridel Guest

    I use RPMs. Cleanest way on my RPM-based systems.
     
    Aredridel, Oct 11, 2004
    #10
  11. On Oct 9, 2004, at 6: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


    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
     
    (Curne) Simon Conrad-Armes, Oct 11, 2004
    #11
  12. Carl Youngblood <> writes:
    > 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
    --
    Come to think of it, there are already a million monkeys on a million
    typewriters, and Usenet is NOTHING like Shakespeare.
    -- Blair Houghton.
     
    Eric Schwartz, Oct 14, 2004
    #12
  13. Eric Schwartz wrote:

    >Carl Youngblood <> writes:
    >
    >
    >>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
    >
    >

    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!)
     
    Charles Hixson, Oct 14, 2004
    #13
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Michel Gallant

    Policy File. Definitive Guide?

    Michel Gallant, Jan 29, 2004, in forum: Java
    Replies:
    2
    Views:
    362
  2. Jeremy Bear

    Definitive Ruby/Tk guide?

    Jeremy Bear, Apr 13, 2005, in forum: Ruby
    Replies:
    5
    Views:
    876
    Jacek
    Apr 21, 2005
  3. Eustaquio Rangel de Oliveira Jr.

    The definitive GUI for Ruby

    Eustaquio Rangel de Oliveira Jr., Oct 4, 2005, in forum: Ruby
    Replies:
    27
    Views:
    306
    Dave Howell
    Oct 6, 2005
  4. highlyjhi

    Two Installations of Ruby

    highlyjhi, May 22, 2007, in forum: Ruby
    Replies:
    6
    Views:
    108
    Tim Hunter
    May 22, 2007
  5. Alex Rice
    Replies:
    6
    Views:
    151
    Alex Rice
    Dec 28, 2009
Loading...

Share This Page