Re: Bug#293055: Progress with rails?
* Paul van Tilburg [Sat, 12 Feb 2005 12:30:44 +0100]:
> Yes that's right, quoting from the RubyGems 0.8.4 source:
> ---
> # We replace Ruby's require with our own, which is capable of loading gems on demand.
> #
> # When you call <tt>require 'x'</tt>, this is what happens:
> # * If the file can be loaded from the existing Ruby loadpath, it is.
> # * Otherwise, installed gems are searched for a file that matches. If it's found in gem
> # 'y', that gem is activated (added to the loadpath).
> #
> # The normal <tt>require</tt> functionality of returning false if that file has already been
> # loaded is preserved.
> ---
> 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.)
> 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.
> 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?)
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...)
> 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.
And that's enough for crazy ideas already. ;-)
--
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
Truth is the most valuable thing we have, so let's economize it.
-- Mark Twain
Reply to: