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. Cheers, Patrick 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. _______________________________________________ Rubygems-developers mailing list [email protected] http://rubyforge.org/mailman/listinfo/rubygems-developers
