On 19/03/10 at 07:14 +0900, Rick DeNatale wrote:
> 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."

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 / lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lucas / nussbaum.fr             GPG: 1024D/023B3F4F |