From: Leslie Viljoen Date: 2010-03-19T05:35:26+09:00 Subject: Re: Recommended way to install Rubygems --00032555850a5e4c400482192baf Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 18, 2010 at 10:07 PM, Lucas Nussbaum 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 --00032555850a5e4c400482192baf--