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

[Mathias Gug]

On Tue, Aug 19, 2008 at 07:28:02PM -0400, Scott Kitterman wrote:
> >On Tue, Aug 19, 2008 at 05:58:39PM -0400, Scott Kitterman wrote:
> >> Which we generally patch into submission when we find it.  In 
> Debian/Ubuntu 
> >> if ezsetup is installing external Python modules it's bug.
> >
> >Do you mean that ezsetup tries to install debian packages of the python
> >modules ?
> 
> No ezsetup tries to download and install modules from outside the packaging 
> system.  Ideally we'd patch that out and the provide proper dependencies to 
> proper packages through the package management system.

IIUC, if ezsetup is used by the upstream source file during the build
phase and downloads an external python module, that portion is replaced
with proper dependencies when creating the package for Debian/Ubuntu.

In the case of the gem command, there isn't any interaction with the
package system.

> >> >Neil's proposal is to improve the gem command (from the libgems-ruby
> >> >package) so that binaries are installed in /usr/local/bin (thus they're
> >> >on the default path). If you'd use install gems from the upstream
> >> >source, binaries would be installed in /usr/bin/. The goal is that gems
> >> >installed by the gem command don't interfere with ruby libraries and
> >> >binaries installed by debian packages.
> >> 
> >> Do you mean NOT on the default path then?
> >
> >No. The binaries included in the gem are installed in /usr/local/bin/,
> >which is on the default PATH.
> 
> Doesn't that mean they'll get used in place of installed system packages?
> 

See my comment below.

> >> >Upstream provided the necessary hooks to do so and Neil used the
> >> >update-alternatives system to handle multiple version of gems being
> >> >installed in /usr/local/bin/ rather than /usr/bin/.
> >> >
> >> It does sound like progress.  As long as we aren't actually packaing the 
> >> gems themselves it seems like a reasonable way to go until Ruby Gems 
> grows 
> >> enough features to support proper integration of gems into the distro 
> >> package space.
> >
> >Exactly. Neil's proposal is *not* aimed at integrating gems with the
> >distro package space but rather improve gem installation from source so
> >that it doesn't conflict with distro packages. Proper integration is a
> >long-term goal and we're looking at the Intrepid timeframe. 
> >
> >The current rubygem package provides a gem command that installs gem
> >binaries in /var/lib/rubyX.Y/bin/ which is not part of the default PATH.
> >Neil's proposal uses update-alternative to make these binaries available
> >in /usr/loca/bin/ so that they're located in the default PATH. End
> >users won't have to modify their environment and gems will work OOTB.
> >
> I can see how this doesn't conflict from an installation perspective, but 
> unless I misremember where that is in the path, it will be used in place of 
> anything provided through the distro.  Am I missing something?
> 

Nope - you're right. Binaries installed by the gem command will be used
in place of binaries provided by packages since /usr/local/bin comes
first on the PATH. 

I assume that users installing gems from source (ie with the gem
command) want to use the upstream version of the gem rather than the one
provided by the distro. Using the gem command to install from source can
be viewed as a local customization of the system by the system
administrator - thus the usage of /usr/local/bin/.

-- 
Mathias Gug
Ubuntu Developer  http://www.ubuntu.com