[Rubygems-developers] Some errors
tobias.luetke at gmail.com
Wed Mar 23 12:44:33 EST 2005
I'm not familiar with gems inner working but perhaps a good approach
to this would be
to figure out all required libraries at the beginning, .uniq! them and
then present a list to the user with
things which are about to be installed asking for confirmation. This
would cut down on the required amount of confirmations for installing
something big like a new rails release as well.
On Wed, 23 Mar 2005 16:17:36 -0000 (UTC), Jim Weirich
<jim at weirichhouse.org> wrote:
> Tobias Luetke said:
> > The 0.8.8.2 installed rails fine.
> > However it installed activesupport a couple times to many but that
> > doesn't do any harm:
> We wanted to make sure it was /really/ installed. :)
> Technical notes if anyone on the list is interested.
> Thanks. The root problem is that the installed "activated" a gem to
> detect if it is installed (activation is the process of putting the gem's
> directories into Ruby's load path). Since the list of versioned gems
> changes as the install proceeds the version of activesupport activated
> early in the install cycle can be different that one activated later (ie.
> after activesupport has been upgraded).
> Since 0.8.8.1 make activation of different versions an error (it always
> /should/ have been an error), the install cycle can cause the error you
> have seen.
> My fix has been to /not/ use activation during an install (although
> activation was a simple way to detect errors, it strikes me as a really
> bad idea ... more below). Instead I just search the source index to see
> if the dependent software is available (which is what activation does
> anyways). The duplication above is probably caused by not reloading the
> in-memory copy of the source index after each installation, causing the
> installer to not realize that "activesupport" is already installed. That
> should be an easy fix this evening.
> BTW, in a related bug, the ICONV problems that a lot of people are
> reporting are caused by using activation to detect the presence of
> dependencies. If a gem has an autorequire property, activating the gem
> will automatically require that piece of the installed gem. The problem
> is that installation is not the proper time to be autorequiring files and
> tends to cause errors. There have been a bunch of reported errors with
> gems over the months where it looks like gems is running non-gem code
> during installation. This is the reason. Using activation for dependency
> presence testing is a /bad/ idea, and the above fix addresses this as
> I should have an update available this evening.
> -- Jim Weirich jim at 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)
http://www.snowdevil.ca - Snowboards that don't suck
http://www.hieraki.org - Open source book authoring
http://blog.leetsoft.com - Technical weblog
More information about the Rubygems-developers