On Wed, Jun 07, 2006 at 03:57:17PM -0400, Jim Weirich wrote:
> I pondered long and hard over the datadir issue and finally decide to
> take a minimalist approach verify similar to Maruicio's first suggestion
> in http://tinyurl.com/b7yo9. I am suggesting that people use
> Config.datadir(package_name) to locate their data directory. In the
> absence of RubyGems, this will just resolve to
> File.join(Config::CONFIG['datadir'], package_name). If RubyGems is
> present, it will locate the 'data' directory in the corresponding
> versioned gem area.
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")
The extra subdirectory is needed because installing stuff right under
CONFIG["datadir"] (with setup.rb or equivalent tools) would not be
acceptable (too prone to name clashes). In other words, while something like
File.open(Config.datadir(package_name) + "foo.dat"){|f| ... }
would be OK when installed with RubyGems, it'd lead to problems with
setup.rb and friends.
This is obvious if one reads the non-RubyGems-enabled definition of
Config.datadir, but people releasing primarily in RubyGems format might
never see it. This is again about promoting good practices that make sw.
installable and usable also without RubyGems.
(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")...
* whose datadir should be chosen if there are several versions of foo
installed? the latest's? If so, a package that is working fine might break
when a new version of a seemingly unrelated package is installed.
(Note that this does not differ from the current situation with
RubyGems' Kernel#require as far as code, as opposed to data, is concerned)
This can be addressed in many ways, but none seems to solve everything
satisfactorily:
* adding explicit version info would work, but it's probably too verbose
(you'd do it as Config.datadir("foo", DATAVERSION) so as to not be
forced to change lots of lines if the specific version changes)
* if the package depends on the one containing the data, the exact
version can be inferred from the RubyGems spec.
*However*, "data dependencies" might not always result in actual
dependencies: it is (or rather, it should be) possible to have a package
recommend/suggest the installation of another one.
(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.
(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.
a-c deserve some further reflection in my opinion. As for (d), I think that
choosing *not* to support it is the right choice.
> This has several real advantages:
>
> * It is compatible with setup.rb (where the data directory defaults to
> 'data'). A project can use a single directory structure to satisfy both
> the gem and setup.rb packaging requirements.
>
> * The application remains unaware whether it is running as a gem or a
> directly installed app.
This is very important. The application will indeed work, but (a) applies.
> * It retains versioned data directories so that we don't break the
> multi-version nature of RubyGems.
(b)
I'll try to spare some brain cycles for this, but these are the first things
that come to mind.
--
Mauricio Fernandez - http://eigenclass.org - singular Ruby
_______________________________________________
Rubygems-developers mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rubygems-developers
