CODEWITHSUNDEEP
rubyperformancerubygemsbundler
dsw88
dsw88

Reputation: 4592

Bundler - bundle package takes forever for a specific gem

Where I work, we develop several Ruby Gems for internal use. They all depend on various combinations of both our own internal gems as well as third-party gems from RubyGems.org.

We automatically build our gems when we make a change using a build server (ElectricCommander) that packages them as gems and stores them in an internal repository. As part of that process, we run bundle package --all. This has been working flawlessly for all our gems until last week.

Last week, one of our gems started taking over 1 hour to run the bundle package command. It runs successfully, but it just takes over an hour to finish, which is a bit absurd.

On our other gem builds, the bundle package command runs just fine in a more respectable minute or so. There's not a huge difference in the amount of dependencies each gem contains. They all build in the same environment.

We're pulling our hair out over this one. A Google search didn't reveal anyone with the same problem. Has anyone experienced this issue, or does anyone know what might be causing it?

Upvotes: 0

Views: 192

Answers (2)

Tim Moore
Tim Moore

Reputation: 9482

Bundler tries very hard to find a set of gems that meets all of your bundle's requirements, but in some cases, this search can take a long time. Depending on the order of gems in your Gemfile, the constraints you provide, and the dependencies encountered in other gems, Bundler might need to backtrack on the resolution process and re-resolve some gems. In worst-case scenarios, this can take exponential time.

Pat Shaughnessy explains the process well in How does Bundler bundle?. As he mentions, running Bundler with DEBUG_RESOLVER=1 in the environment can help show you what's happening.

You can work around these problems by changing the order of the gems in your Gemfile or by using more specific version constraints as Shadwell suggests.

Upvotes: 2

Shadwell
Shadwell

Reputation: 34774

I've had a similar issue before when the gem in question was dependent on another gem that both had many versions and had many other dependencies. In our gem we had the other gem (it was rails) as a dependency without depending on a specific version.

So we had:

s.add_runtime_dependency "rails"

When we added a version we saw a significant increase in bundling speed:

s.add_runtime_dependency "rails", "~>3.2"

With an absolutely rigid version it was even quicker:

s.add_runtime_dependency "rails", "3.2.14"

The reason for the slowness, I believe, is that it looks at all of the dependencies for all of the versions of the gem that match the dependency in your gemspec. As you can imagine with a gem that has been around for a while and which has many other dependencies itself this can get to be quite a significant amount of looking around.

Upvotes: 2

Related Questions