Recommended way to install Rubygems
in [Ruby]
|
From: Lucas Nussbaum on 18 Mar 2010 17:43 On 19/03/10 at 06:27 +0900, gf wrote: > 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. Yes. I will do that when we have a discussion about that on the Debian side again (now is not a good time, we are trying to get a release out). -- | Lucas Nussbaum | lucas(a)lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lucas(a)nussbaum.fr GPG: 1024D/023B3F4F |
From: John W Higgins on 18 Mar 2010 17:44 [Note: parts of this message were removed to make it a legal post.] Good Afternoon, On Thu, Mar 18, 2010 at 1:07 PM, Lucas Nussbaum <lucas(a)lucas-nussbaum.net>wrote: > 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. > I'm rather confused by this - a gem file (at least as far as I can find) contains two files data.tar.gz and metadata.tar.gz within the tar.gz shell of the .gem file - what exactly is the issue with that layout? Is there something specific that this doesn't provide you that is of great importance? > - then we often have to modify the source, to remove the calls to > "require 'rubygems'" > I'm pretty sure that's a one liner for 99.9% of cases and I really don't think is necessary - you really should look at how Gentoo installs gems because we get the benefit of both "manually" installing a package as well as full integration within RubyGems (for example gem list --local shows all gems installed via portage and well as gem install). If there is no ebuild file we can infact turn to emerge-gem to take a gem file and create an ebuild (including full dependency checks from the gem itself). Does it work every single time - nope - but it seems like a huge improvement over what is going on with Debian at the moment. > - 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. > Again, you keep seeming to want to continue to take shot after shot at developers when clearly it's an issue with the ability of Debian to have any flexibility - again looking at Gentoo it somehow, in a very much automated fashion, manages to handle all these wild and wacky libraries. In fact you might want to look at Gentoo as a way to create sources packages because it seems to handle all your issues and will present a nice simple tar.bz2 package of the files that might be much easier to work with in regards to your need for standardization. And I'm truly not saying that to be an idiot or anything - it really seems like Gentoo has solved the issues you are having, at least with respect to getting the files into some form of a constant layout which may be of great help to you. John
From: Rick DeNatale on 18 Mar 2010 18:14 On Thu, Mar 18, 2010 at 2:47 PM, Lucas Nussbaum <lucas(a)lucas-nussbaum.net> 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. I assume you mean that "the user doesn't care whether it's perl or ruby." Actually control, or lack of control over configuration management cuts both ways. I the case of OO base framework code, you can't safely change versions of the framework and the application based on the framework. Back in the late 80s early 90s, everyone got excited over the early application frameworks like MacApp and NextStep, and all of the guys developing operating systems got the idea of building operating systems with frameworks as the API. This just doesn't work. I know, I was there. http://talklikeaduck.denhaven2.com/2007/06/15/a-meeting-with-gill-bates And for those who might be slow, I just switched the first letters in Gill Bates first and last names. <G> MacApp, NextStep, and Rails work only when the application can freeze to a particular version of the framework, moving between versions of the framework inevitably involves some rewrite of the application. This is why it's very wise to freeze gems in a Rails application. And when this is done, by the way, you don't need gems to install the app, you typically deploy it via checking it out from a source code repository, and the gems are put in the right place within THAT APPLICATIONS file hierarchy. I know folks who've been bitten when they haven't vendored gems and deployed to a hosting provider, who took it upon themselves to upgrade the SYSTEM without knowing about the need for independent configuration management for the customer's application(s). And other users got bitten when their hosting provider (or they themselves) upgraded the Ruby 1.8 package and got Ruby 1.8.6 changed out to 1.8.7 before their code, or rails or ... was compatible with 1.8.7. Now I know that 1.8.7 maybe shouldn't have made some of the changes it did, and I argued against this at the time, but it's not a question of who is to blame, it's a question of recognizing that seeing configuration management as solely the concern of system administrators is problematical at best. -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Twitter: http://twitter.com/RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale
From: Rick DeNatale on 18 Mar 2010 18:24 On Thu, Mar 18, 2010 at 5:44 PM, John W Higgins <wishdev(a)gmail.com> wrote: > Good Afternoon, > > On Thu, Mar 18, 2010 at 1:07 PM, Lucas Nussbaum <lucas(a)lucas-nussbaum.net>wrote: > >> 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. >> > > I'm rather confused by this - a gem file (at least as far as I can find) > contains two files data.tar.gz and metadata.tar.gz within the tar.gz shell > of the .gem file - what exactly is the issue with that layout? Is there > something specific that this doesn't provide you that is of great > importance? > > >> - then we often have to modify the source, to remove the calls to >> "require 'rubygems'" >> > > I'm pretty sure that's a one liner for 99.9% of cases and I really don't > think is necessary - you really should look at how Gentoo installs gems > because we get the benefit of both "manually" installing a package as well > as full integration within RubyGems (for example gem list --local shows all > gems installed via portage and well as gem install). If there is no ebuild > file we can infact turn to emerge-gem to take a gem file and create an > ebuild (including full dependency checks from the gem itself). Does it work > every single time - nope - but it seems like a huge improvement over what is > going on with Debian at the moment. > > >> - 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. >> > > Again, you keep seeming to want to continue to take shot after shot at > developers when clearly it's an issue with the ability of Debian to have any > flexibility - again looking at Gentoo it somehow, in a very much automated > fashion, manages to handle all these wild and wacky libraries. > > In fact you might want to look at Gentoo as a way to create sources packages > because it seems to handle all your issues and will present a nice simple > tar.bz2 package of the files that might be much easier to work with in > regards to your need for standardization. And I'm truly not saying that to > be an idiot or anything - it really seems like Gentoo has solved the issues > you are having, at least with respect to getting the files into some form of > a constant layout which may be of great help to you. Putting my self in Lucas' shoes, I have to say that such advice seems like telling a Christian that he should accept Mohammed, or an Arab or Buddhist that If they just accept Jesus as their savior everything will be all right. Me, I'm for freedom of religion, as long as I'm free to practice as I wish. <duck>What have I opened myself up for</duck> Seriously though. Each distro has it's own philosophy and goals. Debian tries to balance stability with keeping up with the latest trends. It appeals to people who like such stability. At times though this has caused problems, the loooong interlude between Woody and Sarge caused a lot of folks to champ at the bit for new stuff. That's one of the reasons Ubuntu got popular, it introduced timeboxed releases so that one could be assured that one would be getting a 'stable' refresh every 6 months or so, and not have to dip into the testing or horror of horrors 'sid' version. Canonical was more aggressive in pulling stuff from the testing branch, reworking it and contributing it back. Personally, I use Ubuntu for my linux boxes, but I still use Ruby and rubygems from source. Lucas' dilemma is that he is trying to deal with a rapidly moving body of software in Ruby and particularly ruby gems, in the context of the conservative debian philosophy. I don't envy him. -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Twitter: http://twitter.com/RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale
From: Lucas Nussbaum on 18 Mar 2010 18:38
On 19/03/10 at 07:14 +0900, Rick DeNatale wrote: > On Thu, Mar 18, 2010 at 2:47 PM, Lucas Nussbaum > <lucas(a)lucas-nussbaum.net> 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. > > I assume you mean that "the user doesn't care whether it's perl or ruby." Yes. I clearly sent too many mails on this list today, but people keep replying to me with interesting comments!! ;) > Actually control, or lack of control over configuration management > cuts both ways. > > I the case of OO base framework code, you can't safely change versions > of the framework and the application based on the framework. Back in > the late 80s early 90s, everyone got excited over the early > application frameworks like MacApp and NextStep, and all of the guys > developing operating systems got the idea of building operating > systems with frameworks as the API. This just doesn't work. I know, > I was there. > > http://talklikeaduck.denhaven2.com/2007/06/15/a-meeting-with-gill-bates > > And for those who might be slow, I just switched the first letters in > Gill Bates first and last names. <G> > > MacApp, NextStep, and Rails work only when the application can freeze > to a particular version of the framework, moving between versions of > the framework inevitably involves some rewrite of the application. > > This is why it's very wise to freeze gems in a Rails application. And > when this is done, by the way, you don't need gems to install the app, > you typically deploy it via checking it out from a source code > repository, and the gems are put in the right place within THAT > APPLICATIONS file hierarchy. > > I know folks who've been bitten when they haven't vendored gems and > deployed to a hosting provider, who took it upon themselves to upgrade > the SYSTEM without knowing about the need for independent > configuration management for the customer's application(s). > > And other users got bitten when their hosting provider (or they > themselves) upgraded the Ruby 1.8 package and got Ruby 1.8.6 changed > out to 1.8.7 before their code, or rails or ... was compatible with > 1.8.7. > > Now I know that 1.8.7 maybe shouldn't have made some of the changes it > did, and I argued against this at the time, but it's not a question of > who is to blame, it's a question of recognizing that seeing > configuration management as solely the concern of system > administrators is problematical at best. Thanks for the very interesting link. I understand why it is necessary to freeze the rails version for an application, and why such framework are a different problem. However, that's only a small part of the issue: most gems that are typically vendored are only used through a relatively simple API, and there's no real reason to vendor and freeze those. And the core+stdlib don't really have valid reasons for significantly breaking the API, especially between versions of Ruby 1.8.7.X. Of course, that requires efforts. But the consequence of not doing that work is that people tend to stay with ancient versions of the interpreter, do not consider it interesting to try newer versions, and we end up with Ruby 1.9: first snapshot package uploaded to Debian 5 years ago, and still not widely used by the Ruby community because the cost of migration is too high. -- | Lucas Nussbaum | lucas(a)lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lucas(a)nussbaum.fr GPG: 1024D/023B3F4F | |