[Rubygems-developers] Getting ready for release 0.9.0

Patrick May patrick at hexane.org
Thu Jun 8 16:32:53 EDT 2006

On Jun 8, 2006, at 3:21 PM, Jim Weirich wrote:

> Patrick May wrote:
>> Jim,
>> I'm forwarding this b/c I didn't see my message get through to the  
>> ruby-gems list, and it looks like this thread is spinning out of  
>> control.
>> A single method #lib_filename (listed below) makes it easy to  
>> store resources relative to the source file, i.e. in the gem.  I  
>> don't see why there is a need to worry about an additional 'data'  
>> silo that has to be kept in sync with the 'gem' silo.
> Thanks for the feedback.  We are not actually keeping a data silo  
> that is separate from the gem data.  When installed as a gem, the  
> data is in the gem directory.
> When installed with setup.rb, the data is stored in whatever  
> setup.rb will put it.  The key is to make sure the app code does  
> not care where it comes from.
> The only problem with your suggestion that I see, is that if the  
> code base is repackaged as an RPM or Debian package, it will not be  
> getting the data from the proper area (a lot of these packages have  
> strong rules on what goes where in the file system).  RubyGems has  
> made a firm commitment to be repackager friendly, so I am trying to  
> avoid these potential problems.

I see... so the requirement for a separate data silo is coming from  
other packaging standards.  And I assume compatibility with other  
packaging structures is a pre-requisite to standardization.

This makes sense, thanks for explaining the situation.



p.s. ruby-gems could still use Kernel#caller when aliasing  
Config.datadir(package_name) to support versioned resources.  The  
stack can help decide between returning the datadir for  
package_name-1.0.0 or package_name-2.0.0.

More information about the Rubygems-developers mailing list