Question on bundle dots and length of Rails 5 bundle runs

[Al Snow]

What do the dots "." stand for during a "bundle install" run?
I am seeing some Rails 5 apps having a LOT of dots and taking a LONG time.
Anyone else seeing LONG bundle runs (the dot part)?

Thanks

[Tim Moore]

Hi Al,

There's a few different parts of the process where Bundler can print dots to indicate progress. Most commonly, it's while the resolver is iterating, trying to find a set of compatible gems that match your requirements. Sometimes, adding constraints to your Gemfile to reduce the space of possibilities that Bundler has to search through can improve the speed.

If you post the complete output from `bundle install` as well as the output from `bundle env`, someone might be able to give you more specific advice.

You can also see more detailed output by running `bundle install --verbose`.

Hope that helps!

Cheers,

Tim

--
You received this message because you are subscribed to the Google Groups "ruby-bundler" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ruby-bundler...@googlegroups.com.
To post to this group, send email to ruby-b...@googlegroups.com.
Visit this group at https://groups.google.com/group/ruby-bundler.
For more options, visit https://groups.google.com/d/optout.

[Al Snow]

As requested:

The following repo is much slower running "bundle" for Rails 5 version vs. the Rails 4.2 version of repo.

• Rails 4.2 repo: https://github.com/atlrug/atlrug4
• Rails 5.0.0.beta1 repo: https://github.com/jasnow/atlrug5
• 'bundle env' gist: https://gist.github.com/jasnow/1c1834136612b2b46d36
• I removed the "Gemfile.lock" file and then run 'bundle install --verbose' command.
• Output gist: https://gist.github.com/jasnow/96e1a7a54f38c327f278
• Specs: M1710 laptop running Ubuntu 14.04

[Tim Moore]

Hi Al,

Yes, that output looks like most of the time is spent in the resolution step, where Bundler is trying to find a set of gems that work together. I can see from the Gemfile that very few of the gems specify a version, so Bundler might have to try a large number of version combinations before it finds ones that work. You can see this process in detail by running "DEBUG_RESOLVER=true bundle install". This produces *a lot* of output, detailing everything the resolver tries, step by step. If you see a gem that it has to retry over and over with different versions, that could be a good candidate for adding a version constraint.

Hope that helps,

Tim

[Al Snow]

Tim,

I will run the DEBUG_RESOLVER, but my point is that something changed between
Rails 4.2 and Rails 5.0 to drastically slow down the "bundle" command and I have
not specifying a version on most of my repos that I regularly maintain for a long time.
Also I have projects for Rails 2.3, 3.0, 3.1, 3.2. 4.0, 4.1, 4.2, 5.0.0.beta, and 5.0.0 edge
so I know what is typical "bundle" speed for these projects.

Thanks for you help,
Al

[Tim Moore]

Al,

That doesn't surprise me, as Rails 5 is still in beta and a lot of gems with Rails dependencies may not have been updated to declare compatibility with Rails 5 pre-releases yet.

Looking at the DEBUG_RESOLVER output, it looks like the main problem comes from transitive dependencies on rack. Rails 5 declares a dependency on the Rack 2.0 pre-release version, however some other gems with rack dependencies restrict it to 1.x versions.

If you look at your Rails 4 Gemfile.lock, you can see that it's using oauth2 1.0.0, which has a dependency on rack ~> 1.2 (that is, greater than or equal to 1.2.0, less than 2.0): https://github.com/atlrug/atlrug4/blob/master/Gemfile.lock#L318

However in the Rails 5 version, it had to backtrack to an earlier version 0.6.1 of the oauth2 gem, which doesn't have a direct dependency on rack: https://github.com/jasnow/atlrug5/blob/master/Gemfile.lock#L429

Note that in order to backtrack to 0.6.1 of oauth2, it also had to use an older version of omniauth-oauth2 (1.0.2 instead of 1.4.0), and an earlier version of omniauth-github. This recursive backtracking to earlier versions with looser constraints is what causes resolution to be slow.

Here's a gist of the relevant DEBUG_RESOLVER output for reference: https://gist.github.com/TimMoore/d7e2051691dd87f4909b

Cheers,

Tim