On Thu, Mar 18, 2010 at 2:47 PM, Lucas Nussbaum <lucas / 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