[Rubygems-developers] Gem autoloading problems

Chad Woolley thewoolleyman at gmail.com
Fri Apr 18 13:29:36 EDT 2008

On Fri, Apr 18, 2008 at 6:07 AM, Donavan Pantke
<avatar at spellboundnet.com> wrote:
> On Friday 18 April 2008 04:01:01 am Eric Hodel wrote:
>  > Be careful not to require any files from 'a' and remove 'a' from the
>  > set of active gems.  (Hard)

Is this hard primarily because you have to follow the entire
dependency tree of A?

>  Actually, some of this harkens back to an earlier thread about categories of
>  dependencies and their handling. In this case, the desired behavior of
>  add_dependency in the specification was to influence the installer to ensure
>  that the right gems with the right versions were installed. Installed, but
>  not necessarily activated. My suggestion right away is just to remove the
>  dependency, but this may make a small, easy to implement portion of the
>  system. The code should be much simpler because we're not really complicating
>  things much.

Different categories of dependencies would help here.  The prior
thread was test vs. build vs. production.  This seems to be yet
another axis - install-time dependencies vs. run-time dependencies.  I
wonder what is the status of this work (Susan?)

If you/we don't want to tackle redefining what dependencies mean in
gemspecs, you can always verify installation manually.  In other
words, don't put the rails (a) dependency in your passenger (b)
gemspec, but still validate at Passenger runtime that SOME version of
rails (a) is installed.  GemInstaller could help here - just ship a
geminstaller.yml which defines passenger's required rails version, and
call GemInstaller.install at passenger start-time - and allow
geminstaller to auto-install or throw an exception if installation
fails.  You could implement this same approach from scratch in to
avoid a dependency on GemInstaller.  You can also look at Rails
itself, which just added similar auto-install behavior that can be
called from rake tasks, which is probably a lot simpler than
GemInstaller's code at this point (I still need to rip out all the
pre-1.0 rubygems legacy support and clean things up...)

Good luck,
-- Chad

More information about the Rubygems-developers mailing list