On Thu, Mar 18, 2010 at 10:07 PM, Lucas Nussbaum
<lucas / lucas-nussbaum.net>wrote:

> 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.
>

Ok, I have created a few gems and I wouldn't mind trying to make my gems
more
Debian friendly. Perhaps these guidelines could be put on a wiki, or
something
like Hoe could check for and warn about some of them.

To make a gem, I usually read these:
http://docs.rubygems.org/read/chapter/5
http://nubyonrails.com/articles/tutorial-publishing-rubygems-with-hoe