Re: Is Bundler Overkill?

On Monday, May 17, 2010 10:40:57 am Intransition wrote:
> On May 15, 3:09 pm, Jeremy Kemper <[e-mail]> wrote:
> > 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.
> 
> Is that a common need?

Yes.

> I doubt I'd use a host that make it necessary
> for me to handle it that way.

I usually wouldn't either, but you can see the appeal of spending, say, $5/mo 
for a managed, shared host, instead of $20/mo for one you have to manage 
yourself.

I mean, I like system administration, but your typical blogger doesn't want or 
need to do that themselves.

There's also Google App Engine. While we don't currently have the latest 
bundler working, we do effectively need it, and it means I get to start 
hosting an app for free with a significant amount of bandwidth and CPU before 
I have to start paying.

> > 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.
> 
> Ah, that's interesting. I did not realize Bundler improves the
> situation a bit by choosing a happy medium, if one exists. Now that i
> know this, I would say it is the one truly significant feature that
> Bundler provides. I would like to see RubyGems itself incorporate this
> capability.

I like that it's separate, and I also don't see how it could realistically be 
imported into Rubygems itself, at least as it's commonly used.

> > '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.
> 
> Ultimately it boils down to the fact that we cannot use two versions
> of the same library in a single process. Ruby could support this, and
> thus remove the need for much of this additional work.

Maybe. Even in that case, though, I would still want a convenient way to 
bundle gems, or to specify one gem depending on another, or to specify my app 
depending on multiple gems. A package manager _is_ the natural result.

I do wish it was better integrated into the system package manager, but I 
don't think replacing everything with debs is a solution, especially seeing as 
not everyone uses Debian or a Debian-derivative.