Recommended way to install Rubygems
in [Ruby]
|
From: Lucas Nussbaum on 18 Mar 2010 16:07 On 19/03/10 at 04:26 +0900, Leslie Viljoen wrote: > On Thu, Mar 18, 2010 at 8:47 PM, Lucas Nussbaum <lucas(a)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(a)lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lucas(a)nussbaum.fr GPG: 1024D/023B3F4F |
From: Leslie Viljoen on 18 Mar 2010 16:35 [Note: parts of this message were removed to make it a legal post.] On Thu, Mar 18, 2010 at 10:07 PM, Lucas Nussbaum <lucas(a)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(a)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
From: Eric Hodel on 18 Mar 2010 17:01 On Mar 18, 2010, at 08:02, Lucas Nussbaum wrote: > On 18/03/10 at 23:31 +0900, James Edward Gray II wrote: >> All of the standard libraries are meant to be >> installed so you can count on having them. By changing that decision, >> Debian has made it so you can't count on having them and that changes >> the rules of what you can do with Ruby. > > If, maybe, the Ruby community fixed the fact that it's illegal to load > all of stdlib in the same process (because of OpenSSL vs GPL), we could > consider including ssl and readline in the default lib pkg. However, I don't > see how we will make Ruby depend on installing Tcl/Tk (because of the TK > bindings), or Emacs (because of the ruby mode for emacs). Note that even > ruby-full doesn't install the TK and elisp stuff. Maybe Debian should switch to a non-GPL readline implementation for ruby as it's not illegal on OS X: $ otool -L `gem which readline` /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/universal-darwin10.0/readline.bundle: /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/libruby.1.dylib (compatibility version 1.8.0, current version 1.8.7) /usr/lib/libedit.2.dylib (compatibility version 2.0.0, current version 2.11.0) /usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 123.0.0) (Ignoring compatibility problems between readline and editline, of course)
From: gf on 18 Mar 2010 17:27 On Mar 18, 11:47 am, Lucas Nussbaum <lu...(a)lucas-nussbaum.net> wrote: > [...] > Instead, we should try to > develop a set of good practices that make it easier to convert a ruby > library into a "normal" Deb or RPM package. Much progress has already > been done lately, and the last libraries I've packaged didn't use > "require 'rubygems'" except in the test suite, so they did not require > any patching. [...] Perhaps talking to the gemcutter people (http://rubygems.org/) to bottleneck the Deb/RPM packaging needs would be productive? That's supposed to be the source for gems now, so building in a hook that does all the necessary tweaks for *nix packaging would tie Windows, Mac OS, gems and Deb/RPM together at the source. Just a thought from my tired ol' mind. http://www.rubyinside.com/gemcutter-a-fast-and-easy-approach-to-ruby-gem-hosting-2281.html http://www.rubyinside.com/gemcutter-is-the-new-official-default-rubygem-host-2659.html
From: Lucas Nussbaum on 18 Mar 2010 17:29
On 19/03/10 at 06:01 +0900, Eric Hodel wrote: > On Mar 18, 2010, at 08:02, Lucas Nussbaum wrote: > > On 18/03/10 at 23:31 +0900, James Edward Gray II wrote: > >> All of the standard libraries are meant to be > >> installed so you can count on having them. By changing that decision, > >> Debian has made it so you can't count on having them and that changes > >> the rules of what you can do with Ruby. > > > > If, maybe, the Ruby community fixed the fact that it's illegal to load > > all of stdlib in the same process (because of OpenSSL vs GPL), we could > > consider including ssl and readline in the default lib pkg. However, I don't > > see how we will make Ruby depend on installing Tcl/Tk (because of the TK > > bindings), or Emacs (because of the ruby mode for emacs). Note that even > > ruby-full doesn't install the TK and elisp stuff. > > Maybe Debian should switch to a non-GPL readline implementation for ruby as it's not illegal on OS X: > > $ otool -L `gem which readline` > /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/universal-darwin10.0/readline.bundle: > /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/libruby.1.dylib (compatibility version 1.8.0, current version 1.8.7) > /usr/lib/libedit.2.dylib (compatibility version 2.0.0, current version 2.11.0) > /usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 123.0.0) > > (Ignoring compatibility problems between readline and editline, of course) It was pointed out that libedit doesn't support multibyte encodings yet, unfortunately. But yes, it is a solution. -- | Lucas Nussbaum | lucas(a)lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lucas(a)nussbaum.fr GPG: 1024D/023B3F4F | |