[Rubygems-developers] Getting ready for release 0.9.0
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:
>> 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
>> 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