TAN: why Bundler? (was: Re: problem with rainbows 3.2.0 and rbx)

Hedge Hog hedgehogshiatus at gmail.com
Sat Apr 30 22:09:38 EDT 2011

On Sun, May 1, 2011 at 3:51 AM, Eric Wong <normalperson at yhbt.net> wrote:
> Eric Wong <normalperson at yhbt.net> wrote:
>> 2) your app uses Bundler?
> Old idea, but I'm not sure why more webapps aren't just distributed as
> gems themselves.

In my case I considered and, after much effort, rejected this
approach.  I'm moving, progressively, to continuous deployment (via
Whiskey Disk).
Having my web app depend on rubygems is a non starter.

The objective is to have the web-app/component deployed in the time it
currently takes to sync the rubygems index and resolve dependencies
(see the Whiskey Disk presentation).
Of course I could use some CDN directly, but you see the path I'd be
heading down: writing a custom package deployer.
Of course I do use Ruby gems for 3rd party library dependencies, and
one thing I'm doing is moving some current 'app-level' code out into a
slow changing gem, but the actual web-app?  Not likely.

>  Or even something like this which just declares
> dependencies:
> ----------------- gemspec_sandbox_demo.gemspec --------------------
> Gem::Specification.new do |s|
>  s.name = %q{gemspec_sandbox_demo}
>  s.version = '1'
>  s.author = "J. Random Hacker"
>  s.homepage = "http://example.com/"
>  s.email = "root at example.com"
>  s.summary = "no need to use sandboxing tools"
>  s.description = <<EOF
> Apps that use gems that don't conflict can just use a dummy gem built
> from a gemspec like this one.
> There are a few missing pieces, like not being able to use git://
> repos for gems or specify build options for C extensions, but it's
> probably enough for a good number of use cases.
>  s.add_dependency(%q<mysql2>, "~> 0.3")
>  s.add_dependency(%q<sequel>, "~> 3.22")
>  s.add_dependency(%q<sinatra>, "~> 1.0")
> end
> -------------------------------------------------------------------
> And then just `gem build foo.gemspec && gem install ./foo-1.gem`
> in the deploy.

Using Git and SSH I'm getting to the point where the deploy will be
done in the time Rubygems index sync's and Bundler resolves its
dependency calculations and actions.

> ...But many years ago I gave up and just decided
> packaging/dependency/deployment problems are just unsolvable

I think of deploying as being _very_ weakly related to packaging and
resolving dependencies.  Before their problems are solvable, their
roles need to be clearly delineated in your app/project.

> because
> there's always (at least) one special case in *every* case that $TOOL
> doesn't/can't solve :<

I'm not sure it is and issue of a 'special case', rather deployment
patterns and _frequency_ are those that package managers were never
intended to address.
In my mind packagers/dependency-resolvers are targeted at the
infrequently-changing-code, and widely adopted use cases.
Say monthly changes as the most frequent - you could push the limits
and maybe have daily gem updates, but now the packager's overhead vs
the size of the change means you'll be more and more reluctant to get
the small change in your deployed code out there - and waiting for
small changes to grow into bigger changes, in my experience, makes
things more complex and more fraught.

I tried hard to fix Bundler's _many_ Git issues, see the pull
requests, but I concluded it is a wasted effort - the core Devs don't
have Git use  cases as one of their itches, and I genuinely thank
indirect for being explicit about this. I realized that maybe they had
reached the conclusion I did: Git in Bundler is really for convenience
of library dev work.
Trying to make it fulfill (continuous) app deployment work is 'nuts'.
If your app deployment is not continuous, then just bundle/gemify it
as usual and use Std Bundler/Rubygems in one of your infrequent
deploys, rather than get Git involved for the sake of having it

My 2c

> --
> Eric Wong
> _______________________________________________
> Rainbows! mailing list - rainbows-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rainbows-talk
> Do not quote signatures (like this one) or top post when replying

πόλλ' οἶδ ἀλώπηξ, ἀλλ' ἐχῖνος ἓν μέγα
[The fox knows many things, but the hedgehog knows one big thing.]
  Archilochus, Greek poet (c. 680 BC – c. 645 BC)

More information about the rainbows-talk mailing list