[#3228] Core support for Gems, and namespace — "Luke A. Kanies" <luke@...>

Hi all,

21 messages 2004/07/27
[#3230] Re: Core support for Gems, and namespace — Austin Ziegler <halostatue@...> 2004/07/27

On Tue, 27 Jul 2004 11:39:08 +0900, Luke A. Kanies <luke@madstop.com> wrote:

[#3234] Re: Core support for Gems, and namespace — "Luke A. Kanies" <luke@...> 2004/07/27

On Tue, 27 Jul 2004, Austin Ziegler wrote:

[#3238] Re: Core support for Gems, and namespace — Austin Ziegler <halostatue@...> 2004/07/27

On Wed, 28 Jul 2004 00:14:29 +0900, Luke A. Kanies <luke@madstop.com> wrote:

Re: Core support for Gems, and namespace

From: Gavin Sinclair <gsinclair@...>
Date: 2004-07-27 15:09:17 UTC
List: ruby-core #3233
On Wednesday, July 28, 2004, 12:48:07 AM, Luke wrote:

> On Tue, 27 Jul 2004, Dave Thomas wrote:

>> On Jul 26, 2004, at 21:39, Luke A. Kanies wrote:
>>
>>> I'm looking at the Gems stuff, and it seems that all scripts will have to
>>> clearly differentiate between libraries installed with gem vs. those
>>> installed by hand.  Is it true that I, as a script writer, will have to
>>> know whether my eventual user installed libraries as Gems?  Even worse, is
>>> it true that all scripts are likely to import the gems libraries?  Why is
>>> not possible to just put all gems in a specific directory, and add that
>>> directory to the library search path?  Does anyone know why this feature
>>> set was chosen?
>>
>> The answer to the second part of your question is versioning. The answer to
>> the first part is the later version of gems, which automatically install
>> stubs into the Ruby library directories. This means that
>>
>>   require 'mylib'
>>
>> will work if mylib was installed as a gem or regularly.

> I don't understand how versioning solves the problem of being forced to
> import an extra library (gems) every time I run a script.

> The stub that gets installed is essentially a sufficient answer; my main
> concern was that I didn't want coders to be forced to either choose 
> between gems libraries and normal libraries, or have every 'require'
> statement be a set of tests looking for one or the other.

A good approach might be the following.  Let's assume your application
or library is called "rfoo" and depends on the following libraries:
redcloth, bluecloth, and madeleine.  We put the dependencies all
together like this, in a file 'rfoo/dependencies.rb'

  begin
    require 'rubygems'
    require_gem 'redcloth'
    require_gem 'bluecloth'
    require_gem 'madeleine', '>= 0.6.0'
  rescue LoadError
    require 'redcloth'
    require 'bluecloth'
    require 'madeline'
  end

Then, throughout your application/library, you can just write

  require 'rfoo/dependencies'

That seems pretty good to me.  Now, let's assume that unconditionally
loading those three libraries is a bad idea performance-wise, because
you don't always need all of them.  Then you can use autoload.
Replace the three "require" statements with:

  autoload :RedCloth, 'redcloth'
  autoload :BlueCloth, 'bluecloth'
  autoload :SnapshotMadeline, 'madeleine'

I've just dug a hole for myself, because require_gem is not usually
amenable to the autoload feature: it automatically loads the default
library, if one is specified.

Anyway Luke, I hope you find something of interest in this response.

Cheers,
Gavin




In This Thread