Closed jtimberman closed 10 years ago
When it's printing the "debug" (ahem) message over and over, and I hit ^C, I see this stack trace:
^C/Users/jtimberman/.rbenv/versions/2.0.0-p247/lib/ruby/2.0.0/forwardable.rb:171:in `name': Interrupt
from /Users/jtimberman/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/solve-0.8.0/lib/solve/solver/constraint_table.rb:20:in `block in constraints_on_artifact'
from /Users/jtimberman/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/solve-0.8.0/lib/solve/solver/constraint_table.rb:19:in `select'
from /Users/jtimberman/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/solve-0.8.0/lib/solve/solver/constraint_table.rb:19:in `constraints_on_artifact'
from /Users/jtimberman/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/solve-0.8.0/lib/solve/solver.rb:251:in `possible_values_for'
from /Users/jtimberman/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/solve-0.8.0/lib/solve/solver.rb:288:in `reset_possible_values_for'
from /Users/jtimberman/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/solve-0.8.0/lib/solve/solver.rb:314:in `block in backtrack'
from /Users/jtimberman/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/solve-0.8.0/lib/solve/solver.rb:313:in `each'
from /Users/jtimberman/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/solve-0.8.0/lib/solve/solver.rb:313:in `backtrack'
from /Users/jtimberman/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/solve-0.8.0/lib/solve/solver.rb:118:in `resolve'
from /Users/jtimberman/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/solve-0.8.0/lib/solve.rb:39:in `it!'
from /Users/jtimberman/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/berkshelf-3.0.0.beta2/lib/berkshelf/resolver.rb:71:in `resolve'
from /Users/jtimberman/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/berkshelf-3.0.0.beta2/lib/berkshelf/installer.rb:43:in `run'
from /Users/jtimberman/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/berkshelf-3.0.0.beta2/lib/berkshelf/berksfile.rb:349:in `install'
from /Users/jtimberman/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/berkshelf-3.0.0.beta2/lib/berkshelf/cli.rb:186:in `install'
from /Users/jtimberman/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/thor-0.18.1/lib/thor/command.rb:27:in `run'
from /Users/jtimberman/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/thor-0.18.1/lib/thor/invocation.rb:120:in `invoke_command'
from /Users/jtimberman/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/thor-0.18.1/lib/thor.rb:363:in `dispatch'
from /Users/jtimberman/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/berkshelf-3.0.0.beta2/lib/berkshelf/cli.rb:52:in `dispatch'
from /Users/jtimberman/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/thor-0.18.1/lib/thor/base.rb:439:in `start'
from /Users/jtimberman/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/berkshelf-3.0.0.beta2/lib/berkshelf/cli.rb:27:in `execute!'
from /Users/jtimberman/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/berkshelf-3.0.0.beta2/bin/berks:5:in `<top (required)>'
from /Users/jtimberman/.rbenv/versions/2.0.0-p247/bin/berks:23:in `load'
from /Users/jtimberman/.rbenv/versions/2.0.0-p247/bin/berks:23:in `<main>'
@jtimberman This does sound like it might be a solve bug, but I'll need to see the graph coming in to Solve to figure it out. I don't think that anybody has ever run Solve against a constraint graph with 200+ demands. That'll definitely slow it down (although the behavior you are describing seems weird)
we have some debugging tools in Solve that we don't really expose anywhere.
1) Serialize out the Solver and we can take a look at the problem / I can load up the problem myself
serializer = Solve::Solver::Serializer.new
solver = Solve::Solver.new(graph, demands) # https://github.com/RiotGames/solve/blob/master/lib/solve.rb#L37
problem = serializer.serialize(solver)
puts problem
2) Turn on tracing by passing an optional UI object to Solve.it! - THIS WILL SLOW THINGS DOWN A LOT
class StupidUI
def say(message)
puts message
end
end
Solve.it!(graph, demands, { :ui => StupidUI.new })
@jtimberman any luck with getting the debug output that @andrewGarson requested?
Haven't had a chance to do that yet :-/. Maybe tomorrow.
I can confirm this behavior in our cookbook setup and am certain that solve is the issue here. The current resolver implementation has a worst case runtime behavior of O(n!)
which can easily result in hundreds of thousands of version satisfaction tests. See #30 for more information.
I'm seeing similar issues with only 17 cookbooks. I updated to 3.0.0.beta4 to try and resolve a dependency version issue, but "berks install" never completes:
$ bundle exec berks version
3.0.0.beta4
$ time bundle exec berks install
DEPRECATED: Your Berksfile contains a site location pointing to the Opscode Community Site (site :opscode). Site locations have been replaced by the source location. Change this to: 'source "http://api.berkshelf.com" to remove this warning. For more information visit https://github.com/berkshelf/berkshelf/wiki/deprecated-locations
Fetching 'wordpress' from git: 'git://github.com/RSTJNII/wordpress.git' with branch: 'master'
Fetching 'cloud_monitoring' from git: 'https://github.com/RSTJNII/cookbook-cloudmonitoring' with branch: 'yum_key-versionfix'
building universe...
<Killed with ctrl-C>
^C/var/lib/gems/1.9.1/gems/solve-0.8.2/lib/solve/graph.rb:164:in `block in artifact_collection': Interrupt
from /var/lib/gems/1.9.1/gems/solve-0.8.2/lib/solve/graph.rb:164:in `each'
from /var/lib/gems/1.9.1/gems/solve-0.8.2/lib/solve/graph.rb:164:in `collect'
from /var/lib/gems/1.9.1/gems/solve-0.8.2/lib/solve/graph.rb:164:in `artifact_collection'
from /var/lib/gems/1.9.1/gems/solve-0.8.2/lib/solve/graph.rb:61:in `artifacts'
from /var/lib/gems/1.9.1/gems/solve-0.8.2/lib/solve/graph.rb:86:in `versions'
from /var/lib/gems/1.9.1/gems/solve-0.8.2/lib/solve/solver.rb:267:in `block in add_dependencies'
from /var/lib/gems/1.9.1/gems/solve-0.8.2/lib/solve/solver.rb:262:in `each'
from /var/lib/gems/1.9.1/gems/solve-0.8.2/lib/solve/solver.rb:262:in `add_dependencies'
from /var/lib/gems/1.9.1/gems/solve-0.8.2/lib/solve/solver.rb:111:in `resolve'
from /var/lib/gems/1.9.1/gems/solve-0.8.2/lib/solve.rb:39:in `it!'
from /home/tom/.bundler/ruby/1.9.1/berkshelf-9aa0bc1612f1/lib/berkshelf/resolver.rb:73:in `resolve'
from /home/tom/.bundler/ruby/1.9.1/berkshelf-9aa0bc1612f1/lib/berkshelf/installer.rb:53:in `run'
from /home/tom/.bundler/ruby/1.9.1/berkshelf-9aa0bc1612f1/lib/berkshelf/berksfile.rb:353:in `install'
from /home/tom/.bundler/ruby/1.9.1/berkshelf-9aa0bc1612f1/lib/berkshelf/cli.rb:143:in `install'
from /var/lib/gems/1.9.1/gems/thor-0.18.1/lib/thor/command.rb:27:in `run'
from /var/lib/gems/1.9.1/gems/thor-0.18.1/lib/thor/invocation.rb:120:in `invoke_command'
from /var/lib/gems/1.9.1/gems/thor-0.18.1/lib/thor.rb:363:in `dispatch'
from /home/tom/.bundler/ruby/1.9.1/berkshelf-9aa0bc1612f1/lib/berkshelf/cli.rb:52:in `dispatch'
from /var/lib/gems/1.9.1/gems/thor-0.18.1/lib/thor/base.rb:439:in `start'
from /home/tom/.bundler/ruby/1.9.1/berkshelf-9aa0bc1612f1/lib/berkshelf/cli.rb:27:in `execute!'
from /home/tom/.bundler/ruby/1.9.1/berkshelf-9aa0bc1612f1/bin/berks:5:in `<top (required)>'
from /var/lib/gems/1.9.1/bin/berks:23:in `load'
from /var/lib/gems/1.9.1/bin/berks:23:in `<main>'
real 3646m53.023s
user 3632m42.990s
sys 0m20.913s
I let that run for 2.5 days, I would have expected it to complete if it was just a O(n!) issue. Ruby did have one core at 100% for the duration of the run. Here is the 'berks install' output of 2.0.10 for comparison:
$ berks version
Berkshelf (2.0.10)
<Snip license>
$ time berks install
Using wordpress-rolebook (0.1.1) from metadata
Installing wordpress (1.3.1) from git: 'git://github.com/RSTJNII/wordpress.git' with branch: 'master' at ref: '34f3f471a2ca62f754aab201699dfd6b9b94703f'
Installing cloud_monitoring (1.0.5) from git: 'https://github.com/RSTJNII/cookbook-cloudmonitoring' with branch: 'yum_key-versionfix' at ref: '833ab818387de449486e009a1e52d4c6261e118b'
Installing iptables (0.12.0) from site: 'http://cookbooks.opscode.com/api/v1/cookbooks'
Using php (1.3.10)
Using build-essential (1.4.2)
Using xml (1.2.0)
Using mysql (4.0.14)
Using openssl (1.1.0)
Using yum-epel (0.2.0)
Using yum (3.0.4)
Using windows (1.12.6)
Using chef_handler (1.1.4)
Using iis (2.0.0)
Using apache2 (1.8.14)
Installing chef_gem (0.1.0) from site: 'http://cookbooks.opscode.com/api/v1/cookbooks'
Using apt (2.3.4)
Installing python (1.4.4) from site: 'http://cookbooks.opscode.com/api/v1/cookbooks'
real 0m19.034s
user 0m1.800s
sys 0m0.364s
I'm not familiar enough with Berkshelf to provide the debugging information andrewGarson requested above at this time. Please also let me know if this should be reported against https://github.com/berkshelf/berkshelf/issues/959. Thanks.
I am also running into this infinite loop issue with version 3.0.0.beta4. I was able to run the debugging commands above (specifically the second one with a File output UI) and got these (truncated to 500K) results. The output kept looping over and over around the "Could not find an acceptable value for virtualenvwrapper" and subsequent re-attempt at "Resetting possible values for virtualenvwrapper" event. The same thing appears to be happening with 'openssl' as well, though as far as I know the 'virutalenvwrapper' and 'openssl' cookbooks are not dependent on each other in any way.
Here is the main Berksfile that the troubled berks install
command is using:
cookbook 'fpn_app', path: 'site-cookbooks/fpn_app'
Inside the 'fpn_app' cookbook, there is another Berksfile which looks like this:
site :opscode
metadata
cookbook 'postgresql', git: 'https://github.com/hw-cookbooks/postgresql.git'
# Use this until https://github.com/blackrobot/chef-virtualenvwrapper/pull/1 is accepted
cookbook 'virtualenvwrapper', git: 'https://github.com/keitwb/chef-virtualenvwrapper.git', branch: 'distlib_fix'
#cookbook 'virtualenvwrapper', git: 'https://github.com/blackrobot/chef-virtualenvwrapper.git'
cookbook 'quoin', path: '/share/code/quoin/quoin-cookbook'
The metadata.rb file for that cookbook is thus:
name 'fpn_app'
maintainer 'Quoin'
maintainer_email 'fpn.dev@quoininc.com'
license 'All rights reserved'
description 'Installs/Configures the ******* site'
long_description IO.read(File.join(File.dirname(__FILE__), 'README.md'))
version '0.1.0'
depends 'git'
depends 'quoin'
depends 'postgresql'
depends 'database'
depends 'nginx'
depends 'apt'
depends 'openssl' # Hack for https://github.com/coroutine/chef-postgresql/issues/10
depends 'virtualenvwrapper'
depends 'python'
It doesn't seem to work with the original virutalenvwrapper repository commented out in the application cookbook's Berksfile or with my bugfix fork. I have tried fixing the version on that dependency but no luck. I'm sure I've got something wrong here as I'm just learning chef/berkshelf, so perhaps somebody knows a workaround until this bug can be fixed?
@keitwb could you send me the entire output by any chance? How long did you let it run before you killed it? Depending on the size of the graph not finding a solution could take a very very long time (weeks).
Full output is here on Dropbox (just shy of 1 million lines). It probably ran for several minutes, I don't think any more than 10 minutes or so. I can't tell for sure but it looks like the output just started repeating the same thing over and over against after the first couple thousand lines of output.
So I'm also getting the same problem here. I've got a bunch of git repos in my Berksfile.
Taking a look at the output from @keitwb it's resetting the possible values for the cookbooks over and over, so it never resolves them.
Is there anything I can do to help diagnose this bug?
@damacus the bug has already been well identified. The only work left now is to re-write the graph solver in Solve or a cross compatible set of FFI/C bindings for Gecode.
Is there a final tracking issue for this? Subscribing.
@nicholasserra we are still working on it/
Looks like I have the same bug.
Berkshelf 3.0.beta7 starts to eat 100% of CPU and gets into an infinite loop
% ruby -v
ruby 2.1.0p0 (2013-12-25 revision 44422) [x86_64-darwin13.0]
% grep berks Gemfile
gem 'berkshelf', :github => 'berkshelf/berkshelf', ref: '776e9'
source 'http://berks-api:26200'
metadata
cookbook "local-cookbook", "= 0.0.1", path: "~/git/local-cookbook"
cookbook "fixture-cookbook", path: "test/fixtures/cookbooks/fixture-cookbook"
It has a few cookbook to resolve from our internal Chef server
DEBUG_RESOLVER=1 bundle exec berks install -d
gives me the following output:
Fetching cookbook index from http://berks-api:26200...
Attempting to find a solution
Adding constraint my-cookbook = 0.1.0 from root
Resetting possible values for my-cookbook
Possible values are my-cookbook-0.1.0
Adding constraint apt >= 0.0.0 from root
...
... all the deps are here ...
...
Searching for a value for my-cookbook
Constraints are = 0.1.0
Possible values are ["my-cookbook", [#<Solve::Artifact:0x007fee5ccc24d0 @graph=.....
...
Could not find an acceptable value for another_cookbook
Unbinding yum
Resetting possible values for another_cookbook
Searching for a value for yum
... here goes an infinite loop
So it fails on another_cookbook
which is a fixture cookbook for serverspec tests located in cookbook-dependency/test/fixtures/cookbooks/another_cookbook.
Pressing Ctrl+C gives the following output:
^C/Users/user/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/gems/solve-0.8.2/lib/solve/graph.rb:164:in `block in artifact_collection': Interrupt
from /Users/user/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/gems/solve-0.8.2/lib/solve/graph.rb:164:in `each'
from /Users/user/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/gems/solve-0.8.2/lib/solve/graph.rb:164:in `collect'
from /Users/user/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/gems/solve-0.8.2/lib/solve/graph.rb:164:in `artifact_collection'
from /Users/user/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/gems/solve-0.8.2/lib/solve/graph.rb:61:in `artifacts'
from /Users/user/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/gems/solve-0.8.2/lib/solve/graph.rb:86:in `versions'
from /Users/user/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/gems/solve-0.8.2/lib/solve/solver.rb:267:in `block in add_dependencies'
from /Users/user/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/gems/solve-0.8.2/lib/solve/solver.rb:262:in `each'
from /Users/user/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/gems/solve-0.8.2/lib/solve/solver.rb:262:in `add_dependencies'
from /Users/user/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/gems/solve-0.8.2/lib/solve/solver.rb:111:in `resolve'
from /Users/user/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/gems/solve-0.8.2/lib/solve.rb:39:in `it!'
from /Users/user/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/bundler/gems/berkshelf-776e9269a719/lib/berkshelf/resolver.rb:73:in `resolve'
from /Users/user/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/bundler/gems/berkshelf-776e9269a719/lib/berkshelf/installer.rb:104:in `install_from_universe'
from /Users/user/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/bundler/gems/berkshelf-776e9269a719/lib/berkshelf/installer.rb:37:in `run'
from /Users/user/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/bundler/gems/berkshelf-776e9269a719/lib/berkshelf/berksfile.rb:364:in `install'
from /Users/user/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/bundler/gems/berkshelf-776e9269a719/lib/berkshelf/cli.rb:143:in `install'
from /Users/user/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/gems/thor-0.18.1/lib/thor/command.rb:27:in `run'
from /Users/user/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/gems/thor-0.18.1/lib/thor/invocation.rb:120:in `invoke_command'
from /Users/user/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/gems/thor-0.18.1/lib/thor.rb:363:in `dispatch'
from /Users/user/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/bundler/gems/berkshelf-776e9269a719/lib/berkshelf/cli.rb:52:in `dispatch'
from /Users/user/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/gems/thor-0.18.1/lib/thor/base.rb:439:in `start'
from /Users/user/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/bundler/gems/berkshelf-776e9269a719/lib/berkshelf/cli.rb:27:in `execute!'
from /Users/user/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/bundler/gems/berkshelf-776e9269a719/bin/berks:5:in `<top (required)>'
from /Users/user/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/bin/berks:23:in `load'
from /Users/user/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/bin/berks:23:in `<main>'
@iroller yup. Definitely looks like the bug. We need to fix solve and that's not an easy task. There are also talks of moving to gecode.
Fixed mine by removing an extra dependency from metadata (https://github.com/sethvargo-cookbooks/users/pull/47). Tried to make a reproducible test case but no luck, only fails when it has a bunch of other internal dependencies, sorry.
this.
@ampledata yes?
Hah, sorry, this is what I'm currently battling myself. I'm seeing the same behavior outlined above, e.g. infinite loop on dep resolution or and/or unresolvable deps on fixture cookbooks.
A work-around I've just tried (and seems to hold) is to specify all deps in my main infrastructure Berksfile. This leads to a lot of duplication, but it works.
A Cookbook:
B Cookbook:
depends 'A'
cookbook 'A', git: 'git@github.com:example/A.git', branch: 'master'
Infrastructure Code:
cookbook 'B', git: 'git@github.com:example/B.git', branch: 'master'
$ berks install
Cookbooks get got, puppies get saved.
Unable to find a solution for demands: B (1.0.0)
Specify all dependencies in the Infrastructure Code Berksfile:
cookbook 'A', git: 'git@github.com:example/A.git', branch: 'master'
cookbook 'B', git: 'git@github.com:example/B.git', branch: 'master'
@ampledata okay - you were just adding that this affects you as well?
So i understand the workaround but is there any way to know which of the dependancies in the tree is causing the problem?
@mansona manually - yes. Automated - working on it.
any pointers for me? the last output for me before it goes nuts is
Searching for a value for apt
Constraints are >= 0.0.0
so that makes me think that the problem is apt... and i'm a bit lost as to what i should do next...
@mansona can u post your entire dependency tree? do you have any cookbooks that are importing a non community version of apt?
is there a good way to do that? get the dependancy tree i mean... or is it just manually going through all metadata.rb files in cookbooks and keeping note of the versions?
We have recently merged #33, which switches to gecode for dependency resolution. While we have not released a new version, this merge closes this issue.
so it's in master but if i do a bundle install it wont bring down this fixed version right? sorry i'm not a ruby guy :wink: where can i "follow" to be notified of a release?
@mansona if you "watch" this project on GitHub, you'll get a notification when we cut a new tag (which will correspond to a new release). You can also subscribe to the RSS feed for the gem: https://rubygems.org/gems/solve.
awesome! thanks guys! just checked ruby gems there now and it looks like you released a version of berkshelf and solve 19 hours ago https://cloudup.com/cBylaGAtBVi i'm assuming these should have the fix?
@mansona yes, the latest beta release (9) of Berkshelf should solve this completely
Hmm... well i'm still having some problems but it's unrelated to this issue (I think) I asked the question on Stack Overflow because I thought it sounded more like an issue with my setup, although any help would be much appreciated
http://stackoverflow.com/questions/22930511/symbol-not-found-when-using-ruby-gem-berkshelf
@mansona the issue you're seeing is because you're using Gecode 4 and not Gecode 3. You can uninstall Gecode 4 and install 3 or wait a few days and there'll be a much easier way for us to get you Gecode.
Yea i guess if you're in the middle of moving a few things around then I should just wait. I managed to install an older version of gecode using help from this SO question but now i'm stuck when i'm trying to use test kitchen because it needs dep-selector-libgecode -v '1.0.0.rc.0'
which i'm guessing is incompatible because i get this error when I try to install it:
ERROR: Error installing dep-selector-libgecode:
invalid gem: package is corrupt, exception while verifying: undefined method `path2class' for #<Psych::ClassLoader:0x00000101beb250> (NoMethodError) in /usr/local/rvm/gems/ruby-2.0.0-p451/cache/dep-selector-libgecode-1.0.0.rc.0.gem
Should we create a new bug that keep track of these dependancy problems or will i just wait for confirmation here?
@mansona you should actually open a ticket with dep-selector-libgecode for that issue. That doesn't look good.
:thumbsup: Glad this is resolved, the change to gecode is delightful.
@reset i've solved all my issues by using the new chef-dk this has solved all but one of my dependancy issues.
@mansona good to hear. What dependency issue was chef-dk not able to solve?
@reset https://github.com/opscode/chef-dk/issues/15 open issue to make it plain sailing for anyone else ;) i'm personally all set now
I'm not sure how to report this bug. It appears to be coming from solve, even though I encounter it with Berkshelf (v3.0.0.beta2). Here's the scenario.
I am working with a large number of cookbooks in an existing
chef-repo
. Most of them are private, and for number of reasons are not in separate repositories nor released on the community site. I want to use the:path
directive for each cookbook for my Berksfile:We have over 200 cookbooks in the directory. I shortcut this with the following in my Berksfile:
When I run
berks install
, it gets tobuilding universe
and then hits an infinite loop. As near as I can tell, through judicious use ofputs
in the solve library, it hits this code path:And variable.value is nil for every cookbook. I put the following line above the if statement:
I see this output:
I'm not sure where else to debug this, or how to get more appropriate information. It appears that this is a solve bug, not a berkshelf bug, so I am reporting it here. However, perhaps this is a berkshelf bug, since it should know about its world because I have all these cookbooks locally (and said so, in the Berksfile).