# Is Bundler Overkill?

**URL:** <https://www.ruby-forum.com/t/is-bundler-overkill/188658>\
**Category:** Ruby\
**Created:** [May 15, 2010, 7:49pm UTC](https://www.ruby-forum.com/t/is-bundler-overkill/188658 "2010-05-15T19:49:37Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![tcsnide](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/eb8c5e/32.png) [@tcsnide](https://www.ruby-forum.com/u/tcsnide)\
**Post date:** [May 15, 2010, 7:49pm UTC](https://www.ruby-forum.com/t/is-bundler-overkill/188658/1 "2010-05-15T19:49:37Z")

</div>

This morning I thought about Bundler for a long time. I ended up  
writing a [blog post](http://trans.github.com/20100515-gemcrazy/%0Aindex.html) 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.

---

<div class="post-metadata">

**Author:** ![tcsnide](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/eb8c5e/32.png) [@tcsnide](https://www.ruby-forum.com/u/tcsnide)\
**Post date:** [May 15, 2010, 9:09pm UTC](https://www.ruby-forum.com/t/is-bundler-overkill/188658/2 "2010-05-15T21:09:48Z")

</div>

On Sat, May 15, 2010 at 10:48 AM, Intransition [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
wrote:

> This morning I thought about Bundler for a long time. I ended up  
> writing a [blog post](http://trans.github.com/20100515-gemcrazy/%0Aindex.html) 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

---

<div class="post-metadata">

**Author:** ![tcsnide](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/eb8c5e/32.png) [@tcsnide](https://www.ruby-forum.com/u/tcsnide)\
**Post date:** [May 16, 2010, 12:48am UTC](https://www.ruby-forum.com/t/is-bundler-overkill/188658/3 "2010-05-16T00:48:06Z")

</div>

You’re not the only one, but I think we’re in the minority. gems have  
been a mess for years, badly documented, and unintegrated with any  
particular OS or distribution. Programmers that issue gems use habits  
that make use of more mature packaging systems difficult. From a  
sysadmin point-of-view, they make Ruby-heavy systems unmaintainable in  
the long-term, as any global “gem install” is likely to break  
applications.

At Bytemark, we’ve started to hack out a better packaging infrastructure  
based on stodgy old .debs, and some automatic scripts to convert sets of  
popular gems to work with lenny & lucid. Our automatically-managed  
systems need one extra apt sources line; we excise explicit use of Gem  
or ‘gem’ binaries where they’re installed, and we just “require” what’s  
needed. It’s turning into packaging bliss.

That means you can only have one system-wide version of any library, and  
that is just FINE thanks 🙂 We think the useful Ruby libraries are  
small in number, and the useful ones are proving themselves with stable  
releases. We can live without those gems which change their APIs every  
minor version - that kind of alpha code needs copying into your app, not  
tied into a scissors-and-glue “packaging” system based on github  
snapshots or other flaky URLs.

We’re in the middle of reinstalling our own apps and Ruby-heavy systems  
without gems, and will share our work later in the year once we’ve  
proved to ourselves it all works.

---

<div class="post-metadata">

**Author:** ![tcsnide](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/eb8c5e/32.png) [@tcsnide](https://www.ruby-forum.com/u/tcsnide)\
**Post date:** [May 17, 2010, 5:41pm UTC](https://www.ruby-forum.com/t/is-bundler-overkill/188658/4 "2010-05-17T17:41:41Z")

</div>

On May 15, 3:09 pm, Jeremy K. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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? I doubt I’d use a host that make it necessary  
for me to handle it that way.

> 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.

> ‘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.

---

<div class="post-metadata">

**Author:** ![tcsnide](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/eb8c5e/32.png) [@tcsnide](https://www.ruby-forum.com/u/tcsnide)\
**Post date:** [May 17, 2010, 5:48pm UTC](https://www.ruby-forum.com/t/is-bundler-overkill/188658/5 "2010-05-17T17:48:42Z")

</div>

On May 15, 6:46 pm, Matthew B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> popular gems to work with lenny & lucid. Our automatically-managed  
> systems need one extra apt sources line; we excise explicit use of Gem  
> or ‘gem’ binaries where they’re installed, and we just “require” what’s  
> needed. It’s turning into packaging bliss.

Sounds interesting. I’d like to know more. How does it compare to  
[GitHub - rtomayko/rpg: Fast ruby package management for unix](http://github.com/rtomayko/rpg) for instance?

> That means you can only have one system-wide version of any library, and  
> that is just FINE thanks 🙂 We think the useful Ruby libraries are  
> small in number, and the useful ones are proving themselves with stable  
> releases. We can live without those gems which change their APIs every  
> minor version - that kind of alpha code needs copying into your app, not  
> tied into a scissors-and-glue “packaging” system based on github  
> snapshots or other flaky URLs.

That reminds me of an old packaging system that came out just before  
RubyGems. It was closely controlled to include only high quality  
packages. Any one recall it’s name?

> We’re in the middle of reinstalling our own apps and Ruby-heavy systems  
> without gems, and will share our work later in the year once we’ve  
> proved to ourselves it all works.

It will be interesting to see what you’ve come up with. Thanks.

---

<div class="post-metadata">

**Author:** ![tcsnide](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/eb8c5e/32.png) [@tcsnide](https://www.ruby-forum.com/u/tcsnide)\
**Post date:** [May 17, 2010, 8:06pm UTC](https://www.ruby-forum.com/t/is-bundler-overkill/188658/6 "2010-05-17T20:06:16Z")

</div>

On Monday, May 17, 2010 10:40:57 am Intransition wrote:

> On May 15, 3:09 pm, Jeremy K. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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.

> > 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.

---

<div class="post-metadata">

**Author:** ![tcsnide](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/eb8c5e/32.png) [@tcsnide](https://www.ruby-forum.com/u/tcsnide)\
**Post date:** [May 17, 2010, 6:08pm UTC](https://www.ruby-forum.com/t/is-bundler-overkill/188658/7 "2010-05-17T18:08:01Z")

</div>

On May 17, 2010, at 10:48 AM, Intransition wrote:

> That reminds me of an old packaging system that came out just before  
> RubyGems. It was closely controlled to include only high quality  
> packages. Any one recall it’s name?

I believe it was called RPA.

James Edward G. II