[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: