[#3113] Problem in RSS library, or problem in my blog :) — Dave Thomas <dave@...>
I've been trying to use the new RSS library to parse a number of
7 messages
2004/07/01
[#3136] Wrong rdoc formatting in {array,pack}.c — Johan Holmberg <holmberg@...>
7 messages
2004/07/05
[#3162] Re: [doc-patch] Wrong rdoc formatting in {array,pack}.c
— "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
2004/07/09
Hello.
[#3170] Another rdoc formatting error in array.c
— Johan Holmberg <holmberg@...>
2004/07/10
[#3172] Re: [doc-patch] Another rdoc formatting error in array.c
— "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
2004/07/12
Hello.
[#3141] rexml/validation/validationexception is missing. — nobu.nokada@...
Hi,
5 messages
2004/07/06
[#3154] Nonblocking socket connect - Win32 - 181 — "Jean-Francois Nadeau" <jean-francois.nadeau@...>
Hi,
4 messages
2004/07/08
[#3167] Inconsistent "call-seq" usage etc. — Johan Holmberg <holmberg@...>
7 messages
2004/07/09
[#3168] Re: [doc] Inconsistent "call-seq" usage etc.
— Dave Thomas <dave@...>
2004/07/09
[#3171] binding a URL to a label in RDoc — Ian Macdonald <ian@...>
Hello,
6 messages
2004/07/12
[#3199] Trying to understand \G — Dave Thomas <dave@...>
I'm being silly again, but I can't get \G to work with String.index. If
12 messages
2004/07/16
[#3213] Typo and grammar/style fixes for ext/win32ole/win32ole.c — Jos Backus <jos@...>
The attached patch attempts to create a more consistent style for error
4 messages
2004/07/19
[#3216] Re: Incident Analysis of the intrusion on helium.ruby-lang.org May 2004 — "Sean E. Russell" <ser@...>
Hi,
6 messages
2004/07/21
[#3228] Core support for Gems, and namespace — "Luke A. Kanies" <luke@...>
Hi all,
21 messages
2004/07/27
[#3229] Re: Core support for Gems, and namespace
— Dave Thomas <dave@...>
2004/07/27
[#3232] Re: Core support for Gems, and namespace
— "Luke A. Kanies" <luke@...>
2004/07/27
On Tue, 27 Jul 2004, Dave Thomas wrote:
[#3233] Re: Core support for Gems, and namespace
— Gavin Sinclair <gsinclair@...>
2004/07/27
On Wednesday, July 28, 2004, 12:48:07 AM, Luke wrote:
[#3235] Re: Core support for Gems, and namespace
— "Luke A. Kanies" <luke@...>
2004/07/27
On Wed, 28 Jul 2004, Gavin Sinclair wrote:
[#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:
[#3243] Re: Core support for Gems, and namespace
— Gavin Sinclair <gsinclair@...>
2004/07/28
On Wednesday, July 28, 2004, 3:23:46 AM, Austin wrote:
[#3248] Re: Core support for Gems, and namespace
— Austin Ziegler <halostatue@...>
2004/07/28
On Wed, 28 Jul 2004 11:29:53 +0900, Gavin Sinclair
[#3249] Re: Core support for Gems, and namespace
— Mauricio Fern疣dez <batsman.geo@...>
2004/07/28
On Wed, Jul 28, 2004 at 11:29:53AM +0900, Gavin Sinclair 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