[Rubygems-developers] Getting ready for release 0.9.0

Mauricio Fernandez mfp at acm.org
Wed Jun 7 19:11:47 EDT 2006

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  
  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
  * 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?
    could return nil or an empty/nonexistent dir when someoptionaldep is not

(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
  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.


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

More information about the Rubygems-developers mailing list