Ruby on Rails support in Intrepid - call for reviewers and cheerleaders

[Scott Kitterman]

On Thu, 21 Aug 2008 12:42:58 -0500 David Portwood <dzp at bellsouth.net> wrote:
>On Wed, 2008-08-20 at 15:31 +0200, Stephan Hermann wrote:
>> On Wed, Aug 20, 2008 at 02:07:46PM +0100, Neil Wilson wrote:
>> > Scott,
>> > 
>> > I'm trying to avoid the wheres and wherefores of what gem is about.
>> > Suffice to say that Rails depends upon effective gem support, such
>> > that the configuration of Rails can specify gem dependencies directly.
>> > 
>> > So if Ubuntu wants Rails, it has to have Gem that works. Therefore I
>> > saw my task as trying to get gem to work as a user would expect it to
>> > work without gem destroying the operating system, leaving cruft lying
>> > around the filesystem in the wrong place and try and prevent it
>> > running into itself too much
>> > 
>> > It's an exercise in containment.
>> 
>> What about teaching ROR to use an overlay, especially for the webapp you
>> code for?
>> 
>> I mean, the problem with gem is known...it's nasty...
>> afaik gem can do something like a destdir install somehow (when I'm not
>> mistaken and my mind is working in normal parameters, and my knowledge
>> from old ROR times is still valid).
>> If you have such a structure:
>> 
>> /var/www/ROR_App1/<... std ror dirs ...>
>> /var/www/ROR_App1/gems/<gem1> ...
>> 
>> this gems dir will be used as overlay, so somehow it needs to be
>> possible to LD_PRELOAD/LD_LIBRARY_PATH this directory (via config in
>> apache2/lighty/whereever)
>> 
>> > >>What are you referring to exactly ? Which use case do you have in 
mind ?
>> > >
>> > >It's my understanding that gems produces one complete package (gem) 
with
>> > >all Ruby libs needed to run the application and that there is no 
internal
>> > >notion of versioning.
>> > 
>> > Think of gem as a source package that generates binary packages on the
>> > fly. It has notions of build dependencies with other gems (including
>> > versioning) and run dependencies.
>> > 
>> > One thing it can do is manage several versions of the same gem on the
>> > machine at the same time.
>> > 
>> > For example the Rails gem depends upon the rake, activesupport,
>> > activerecord, actionpack, actionmailer and actionresource gems. You
>> > can install multiple different versions (usually one of each minor
>> > revision - 1.2.6, 2.0.2 and 2.1.0) and gem will ensure that the
>> > correct versions of the dependent gems are brought in at run time.
>> 
>> As long as gems are only delivering their own binaries...
>> But gems are much more, you can include complete (one or more) upstream
>> packages (I had this at one ocasion, there was this imagemagick gem and
>> this module was only working with a special imagemagick version, so it
>> shipped it together with the other cruft, but instead of installing it
>> somewhere where this imagemagick lib didn't hurt, it was just a smartass
>> and installed it in /usr/lib, overwriting the distro imagemagick).
>This is a good example of that, and it happens on more than just debian
>systems.  I do however feel that Neils proposed change(s) to the gems
>package has the best intrest in mind without major changes to gem and
>apt.  This is a step forward, no?

I think that if gem was installing dependencies in a location that would 
not interfere (e.g. be used instead of) installed system libraries, but 
that the installed Gem could use the I could say yes to this.

Scott K