On 19/03/10 at 04:26 +0900, Leslie Viljoen wrote:
> On Thu, Mar 18, 2010 at 8:47 PM, Lucas Nussbaum <lucas / lucas-nussbaum.net>wrote:
> 
> > On 19/03/10 at 02:49 +0900, Aldric Giacomoni wrote:I think that rubygems
> > and emerge and actually quite similar, which
> > probably explains why they work together well. Rubygems is a great tool
> > for developers who want to get the latest cutting edge software.
> > However, at some point, applications are transferred from developers to
> > sysadmins, and "cutting edge" isn't really a good selling point.
> > Internally (in an organization) it's fine, because you can just
> > vendorize all the gems you use. But if you want to distribute your
> > application to the outside world, it's difficult to explain that the
> > user needs to use rubygems to install that application because it's
> > written in ruby, while the ruby is just interested in the functionality
> > provided by the application, and doesn't care whether it's perl or ruby.
> >
> 
> Can I ask: how do Perl and Python deal with this? CPAN is included in the
> base Perl install - how does Perl deal
> with the fact that CPAN then installs its own stuff?

CPAN only installs its own stuff when the user requests it. However,
most of the useful CPAN is packaged in Debian. Packaging perl modules is
very easy, because:
- they are provided as .tgz
- they all share exactly the same interface for compilation and testing
- that interface doesn't require any external dependencies
(I'm not very familiar with python packaging, but I think that it is
similar)

As a result, Debian currently contains more than 2000 perl libraries,
about 1400 python libraries, and only ~300 ruby libraries.

With ruby libraries:
- it is usually difficult to find a usable source. Sometimes we have to
  extract the gem and convert it to a tgz. We also have a service
  (githubredir.debian.net) that allows us to fetch a specific tag on
  github as a .tgz.
- then we often have to modify the source, to remove the calls to
  "require 'rubygems'"
- then we have to find a way to install the files. If the directory
  structure uses the setup.rb standard (bin/, lib/, etc...), then it's
  easy, and we use our own copy of setup.rb to install everything.
  But some libraries don't ship the files in a very organized way.
- Then we have to find a way to run the test suite during the build.
  Since all packages in Debian are frequently rebuilt for QA purposes,
  it is a good way to detect regressions. Unfortunately, using "rake
  test" is usually not an option, because of the way the Rakefile is
  written (dependencies on other stuff including rubygems, etc). So, in
  most cases, we just run the test manually (cd test ; ./ts_*.rb) or
  give up and do not run the test suite automatically during the build.

Also, we would like to support two ruby versions (1.8 and 1.9.X),
which is often difficult because 1.9.X compatibility is rarely
mentioned in the library documentation.

> Is it safe to install RubyGems via apt-get now? I have seen warnings but I
> don't know the actual reason behind them.

Even if I said "yes", I'm probably not the one to trust on that :P
-- 
| Lucas Nussbaum
| lucas / lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lucas / nussbaum.fr             GPG: 1024D/023B3F4F |