[Rubygems-developers] Getting ready for release 0.9.0

Mauricio Fernandez mfp at acm.org
Thu Jun 8 08:16:06 EDT 2006

On Wed, Jun 07, 2006 at 07:38:17PM -0400, Jim Weirich wrote:
> Mauricio Fernandez wrote:
> > A few unprocessed thoughts:
> > 
> > (a) the documentation will have to insist on the necessity of putting the 
> >   data under  
> >     data/myproject
> >   and using 
> >     File.join(Config.datadir(package_name), "myproject")
> Ahh, setup.rb installs directly into CONFIG['datadir'], doesn't it. 
> Hmmm ... missed that when reviewing setup.
> Let's see, the non-gem version of datadir() is ok, because it appends 
> the project name.
> The gem version should return File.join(gem_location, 'data', gem_name). 
>   Then you have to use the extra level in both cases.
> Good catch.

There's another separate but somewhat related issue: stuff installed under
DATADIR *but* not under DATADIR/myproject: manpages, etc, which would not be
supported by the proposed scheme. But I don't think it's worth supporting
anyway at this stage (other mechanisms can be added later).

> > (b) Can the argument to Config.datadir be used to access data 
> >   from another package? At that point we can run into versioning
> >   problems: given  Config.datadir("foo")...
> If we were to allow access to another package's data, then the package 
> must be loaded before that access can occur, then we can use whatever 
> version is loaded.

Oh, but a "data dependency" doesn't always imply a "code dependency": maybe
no #require() was performed...

> > (c) Optional dependencies and "data discovery": code using CONFIG["datadir"]
> >     could run Find.find() on that dir to search for stuff. Should that be
> >     supported at all? (my tentative answer is: not with
> >     Config.datadir(package_name), if at all) What about trying to see if data
> >     from a known package is available?
> > 	Config.datadir("someoptionaldep")
> >     could return nil or an empty/nonexistent dir when someoptionaldep is not
> >     available.
> Woah.  Do you see a big need for this?  I am inclined to not provide 
> this until I understand the usecase better.  If we do disallow access 
> from outside packages, then this seems like a moot point, correct?

Right, if it is disallowed altogether, the problem doesn't exist anymore.
(How to disallow it though? Nothing can be done to prevent this in code not
loaded with RubyGems, and even in that case we can at most generate a runtime
exception --- it'd be best to make it impossible to create a broken package
to begin with, statically so to speak).

A few (very few?) people could miss it though. Imagine I create a ps-writer
lib that can use generate/use type 3 fonts; I happen to know that pdf-writer
ships with some ttf files, so I can try to find them at runtime to generate
some fonts. In this case, pdf-writer is optional and even if it is available
and I can use its data files, at no point do I have to require 'pdf-writer'.
Just having Config.datadir("pdf-writer") return nil if pdf-writer is not
installed would be enough in that case. But (b) must be solved if access to
other package's datadir is allowed, of course.

Mauricio Fernandez  -   http://eigenclass.org   -  singular Ruby

More information about the Rubygems-developers mailing list