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?
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?
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 ?
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
···
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?
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
···
On Sat, 9 Oct 2004 17:19:41 +0900, Mathieu Blondel <matt@enlevemoica.ffworld.com> 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 ?
Carl Youngblood <carl.youngblood@gmail.com> 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!)
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@grayproductions.net> [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
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 jim@weirichhouse.org 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)
James Edward Gray II 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.
···
On Sun, Oct 10, 2004 at 05:09:21AM +0900, Jim Weirich wrote:
>On Oct 9, 2004, at 5:43 AM, Chad Fowler wrote:
--
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com
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).
···
On Sun, Oct 10, 2004 at 05:09:21AM +0900, Jim Weirich wrote:
--
-- Jim Weirich jim@weirichhouse.org 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)