On 9/30/05, Hugh Sasse <hgs / dmu.ac.uk> wrote:
> On Sat, 1 Oct 2005, Jim Weirich wrote:
>> Actually, RubyGems is entirely silent on the matter of data storage.
>> Thus the problem of individual authors doing the relative file path
>> thing.

>> If RubyGems provided a option to copy files in to a area designed by
>> Config::CONFIG['datadir'], would that be adequate?

No. I've already addressed why this won't be adequate, but briefly ...

Both Ruwiki and PDF::Writer have data that is version-dependent. Ruwiki
has two sets of data -- a read-only copy of the default Wiki to provide
instructions, etc., and a deployment package. Both of these are highly
version-dependent. PDF::Writer has the manual (manual.pwd) which is
version-dependent. The images used in the manual and demos is mostly
independent of version, but may be version-dependent in a future
release. PDF::Writer also has data (the .afm font metrics) that is
(mostly) version-independent, although if a new version of the .afm
files is released, they should be version-dependent.

This is currently managed with the File.dirname(__FILE__) hack, and the
.afm situation is actually better than might be imagined, but it's still
a bit of a mess.

As I've said, this is a *Ruby* problem, not a RubyGems problem, but I
believe that RubyGems has an opportunity -- and perhaps a
responsibility, given the versioning -- to solve this for Ruby.

> Excuse me jumping in on this point: I think there are a few things
> we need of this type:
>    A space for data that is Read Only [...]
>    A space for data that is likely to change, like in /var/...
>    A space for Architectural-dependent data. [...]

I agree with this in general. /var-type data should probably be
location-managed by the application, but it'd be nice to be able to get
nice and useful defaults from Ruby itself.

-austin
--
Austin Ziegler * halostatue / gmail.com
               * Alternate: austin / halostatue.ca