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