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.
> (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.
However, I am inclined to make the rule that access to the package's
data area is off limits to code outside the package ... for all the
reasons you list.
> (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?
> (d) with setup.rb, different packages could be providing the same data (as if
> we had a normal name clash, but done deliberately and hopefully resulting
> in everything working fine); this becomes impossible with
> Config.datadir("foo")
> I think that's a good thing.
Agreed.
> I'll try to spare some brain cycles for this, but these are the first things
> that come to mind.
Thanks for the feedback.
-- Jim Weirich
_______________________________________________
Rubygems-developers mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rubygems-developers
