From: Jeremy Kemper <jeremy@...>
Date: 2010-05-16T04:09:11+09:00
Subject: Re: Is Bundler Overkill?

On Sat, May 15, 2010 at 10:48 AM, Intransition <transfire@gmail.com> wrote:
> This morning I thought about Bundler for a long time. I ended up
> writing a <a href="http://trans.github.com/20100515-gemcrazy/
> index.html">blog post</a> on the subject. I realize some of my
> assumptions about "why" may be somewhat off, but certainly they still
> apply even if they are not the direct teleological causes.

'Primary of these [...] The rationalized benefit being that you need
never worry about remote services going down'

At most, this is a beneficial side effect.

'As for the fear of "monkey releases", i.e. new versions of a gem that
that might break an app, this is somewhat understandable but
redistributing every dependency with each app is shear overkill.'

Most developers use ~> for conservative gem dependencies with good results.

You needn't redistribute every dependency with each app. You do have
the option to conveniently package them all if you're deploying to,
say, a shared host.

'If you are that concerned a gem will break an application, one can
always specify exact requirements in the gemspec, and use the gem
method to nail the version down. That, in fact, is the whole point of
the gem method'

'And the second, more significant issue that RubyGems, and hence
Bundler, cannot resolve being version conflicts. RubyGems blows-up
when it encounters a conflict. Bundler only mitigates this issue by
giving you a heads up before you ever run your tests.'

RubyGems resolves gem dependencies at runtime. If an incompatible
version is already activated, it raises an exception. This is a
perfectly cromulent way to handle version conflicts for most people,
most of the time.

Bundler globally resolves the graph of gem dependencies at boot time
instead of runtime. This handles the case where you use two libraries
which depend on a common third library, but with overlapping version
requirements. Resolving serially, at runtime, results in a version
conflict, but resolving globally picks a version of the common third
library that works for both.

'This is the real heart of the matter, and it stems from the
fundamental lack of version support in Ruby itself.'

I don't understand your conclusion.

jeremy