Closed trilitheus closed 8 years ago
Hello! You're probably seeing https://github.com/berkshelf/berkshelf/issues/1377. As far as we can tell, this is a Berkshelf issue combined with the Supermarket endpoints. We're in the same boat you are, short of renaming the cookbook (and that will just put off the inevitable).
Hey there, yeah - this is exactly it.
Interestingly, I've just created a Policyfile and run chef install
- this has no problems resolving correctly.
So if I want to wrap this cookbook in it's current state, I have to fork it, rename it and then reference it in the wrapper's Berksfile? Is there a different workaround?
@dschlenk & others -- there is active work on Berkshelf to make pluggable dependency solvers. Please stay tuned -- as they get implemented, I will definitely be updating this issue.
Here's what I ended up doing:
Comment out all the dependencies in metadata except elasticsearch
. Run berks install
. Uncomment logstash
; run berks install
again. Repeat with kibana_lwrp
. Then repeat a final time after uncomment the rest of the dependencies. @martinb3 maybe check in your lock file until there's a resolution from Berkshelf?
With the merge of #172, there's now a usable Berksfile.lock in the repo for everyone to use.
Hi, Using chefdk0.9.0 on OSX, if I clone this cookbook and run 'berks install' - it times out unable to resolve. Also tried using a blank 'wrapper' cookbook which depends only on 'elkstack', '~> 6.0.0' with the same results. I span up a clean Ubuntu 14.04 VM and did the same also with the same results. I'm having no issues with any other cookbooks. I can add any more details you require. Thanks!