[Rubygems-developers] Getting ready for release 0.9.0

Hugh Sasse hgs at dmu.ac.uk
Thu Jun 8 05:19:56 EDT 2006

On Wed, 7 Jun 2006, Jim Weirich wrote:

> Ahh, setup.rb installs directly into CONFIG['datadir'], doesn't it. 
> Hmmm ... missed that when reviewing setup.
> The gem version should return File.join(gem_location, 'data', gem_name). 
>   Then you have to use the extra level in both cases.
> > (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.

Also breaks the idea of encapsulation.  I think most, but cannot
assert "all", gems result in some object coming into being.  I can't
see from the online docs if a gem can use reflection to get its own
version, and I not done enough dev to know.  If it could, (pretend
this ia a patch):

   module Config
     unless Config.respond_to?(:datadir)

       # Return the path to the data directory associated with the given
       # package name.  Normally this is just
       # "#{Config::CONFIG['datadir']}/#{package_name}", but may be
       # modified by packages like RubyGems to handle versioned data
       # directories.
       def Config.datadir(package_name)
-        File.join(CONFIG['datadir'], package_name)
+        path = File.join(CONFIG['datadir'], package_name)
+        return yield path


which may be subject to your:
> The gem version should return File.join(gem_location, 'data', gem_name). 
above.  Then a gem could

Config.datadir(gemname){|path| File.join(path, Gem.version(gemname))

or something, where I just dreamt up Gem.version() to do the
reflection I mentioned.

This is a clumsy way of saying Config.datadir(gemname) should only
really be used within the encapsulation of the gem itself, and the
resulting object should provide an attr_reader to it.  In which case
the resulting object could use reflection and by means of a block
modify the path to get it correct.

(The above explanation is so long that I feel I have proposed an
overengineered solution ("Why not have a large number of autonomous,
intercommunicating robots to mow your lawn?").)

Anyway, apart from such ramblings, the proposed change to rubygems
sounds good to me.


More information about the Rubygems-developers mailing list