Google Groups

Bundler 1.1 Update - fixing the gem list cache

globalkeith Dec 8, 2011 1:06 PM
Posted in group: ruby-bundler
Ok so before I start, let me say that I love bundler, it definitely
makes my life infinitely better.

This post is about the issue of speed to execute bundle update/install

The issue centres on this "Fetching source index for

Its obviously a problem because why would someone want to time it:

Anyway, it seems the bundler team have attempted to resolve it, and
its explained very nicely here:

My issue is this:

The current version of bundler downloads the whole list each time -
what is wrong with doing a sha1 on the file (both client and server)
and client checks the sha1 with the server - if there are differences,
get the diff patch and apply it. So the first time you run bundler
with new gem host it might take a while to get the list, after that it
will be lightning fast.

And if you're going to say to me, how can the server provide a
diff.patch - for the client to have a file in the first place it must
have downloaded it in the past, therefore the "old list" came from the
server - so the server simply needs basic git functionality of "diff
oldlist newlist".

Something like the following should be sufficient on the server side:<my-list-sha1>

return if my-list-sha1 == latest-list-sha1
return diff get_list(my-list-sha1) get_list(latest-list-sha1)

def get_list(sha1)
  #resolve sha1 to a file however you see fit

This approach would make it very simple implement support on any
custom gem servers - heck the code could even be hacked up in a gist.

So what are the problems with this solution?

The only one I can think it portability of "diff" and "sha1" though
I'm sure that's been solved as well.

Anyway I would be very keen to hear thoughts and opinions about this.
I realise its already too late to influence the internal design of
bundler but it would be great to understand why this concept has been
rejected (I'm assuming they already thought of something like this)