Re: Bug#293055: Progress with rails?
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: paulvt@debian.org
University of Technology, The Netherlands | JID: paul@luon.net
>>> Using the Power of Debian GNU/Linux <<< | GnuPG key ID: 0x50064181
Reply to: