On Sat, Feb 12, 2005 at 03:09:16PM +0100, Adeodato Sim� wrote: > * Paul van Tilburg [Sat, 12 Feb 2005 12:30:44 +0100]: > > The require override first does a linear search through all Gems and > > then it falls back to the normal require. > > Mmm, just to make sure: shouldn't the order be reversed? (To match the > description above.)
You are right, it does a normal require first. > > A solution could be to let the "Ruby super package" (whatever it is > > going to be called) install a rubygems.rb that does nothing but give > > warnings until someone installs the real Rubygems package which diverts > > it. > > Sounds doable, and a possible solution. > > > --- > > # rubygems.rb - dummy lib > > > warn "Rubygems required but not installed, falling back to local installed > > libs." > > I would consider dropping this one warning, it would get triggered too > often for nothing AIUI. ok... maybe if $DEBUG... if an application totally relies on require 'rubygems' require 'somegemlib' then you want to know why this fails. > > module Kernel > > > def require_gem(path) > > warn "require_gem should not be used when RubyGems are not installed, " > > "falling back to local installed libs." > > require(path) > > end > > > end > > --- > > > It would bring source compatibility for Debian for both gem and not > > non-gem applications/libraries. However, this too, is a hack and I am > > not sure what will happen if someone installs RubyGems from > > source/natively. > > Well, if the users install RubyGems by hand, it will be under > /usr/local/lib/site_ruby/1.8, which takes precedence over distribution > paths, so there should be no problem. And the rubygems.deb package > could divert the file rubygems.rb. (We are assuming that the dummy > rubygems.rb file would belong in libruby1.8, right?) Erm, I was assumming this, yes. OK, this is less of a problem then. I just never want to assume that if someone is said to be doing local installs that he knows what he is doing. > The real improvement/innovation here (and we could learn about how > does Perl in Debian do it, I'm not familiar at all with it) would be > that rubygems.deb (and rpa-base.deb?) provided a mechanism to make > dpkg aware of the non-deb things installed, which would be a plus for > installing RubyGems and RPA from Debian instead of by hand. (I'm being > intentionally vague here...) But, how to make 'dpkg' aware... it is mostly not aware of the contents it installs. Possibly ruby lib postinst scripts could warn if a newer version is installed, but this will all be very kludgy. Maybe you're a bit to vague :) > > Hmm, the user quide still does so. Maybe this is because require_gem can > > do something extra, namely one can add a version requirement: > > > require_gem "gem_name", [version_requirement] > > Hmmm, we could check if it could be possible to implement a proper > 'require_gem' in the dummy rubygems.rb file, that would check the > version of the non-gem version. Doesn't sound easy, but a little of > thought could be put into it. Yes, that is some work, but it shouldn't be that hard. Paul -- Student @ Eindhoven | email: [EMAIL PROTECTED] University of Technology, The Netherlands | JID: [EMAIL PROTECTED] >>> Using the Power of Debian GNU/Linux <<< | GnuPG key ID: 0x50064181 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
