I'd do a combination of both:
* in the top-level (or application or wrapper) cookbook representing your node pin all dependency version in the metadata.rb
* in the environment pin only the top-level cookbook's version
This way you can have both versions of Cookbook1 at the same time being used in the same environment (on different nodes though)
For the dependency resolution tools this means that you can _not_ have a per chef-repo Cheffile / Berksfile (they would report exactly the conflict you mention
Thanks AJ,So, currently we don't have this situation, but it came up as a hypothetical situation when we started discussing the library/wrapper paradigm. Currently today we do use environmental constraints, and rarely rely on the setting a version in the cookbooks metadata.rb.That said, the trend we felt like we were seeing is folks suggesting to use the wrapper cookbook s(I think some are calling them Top Level Cookbooks in a slightly different context) and to pin dependencies in the metadata.rbAs we are seeing it the environment approach is known to us ,and typically we've been happy with that approach. It has the down side of an "all or nothing" when we bump a dependency, but since we go through a few levels of environments before we get to something important that has so far been ok for us.So we were looking to try and draw a parallel in the wrapper/library situations. We understand there is no right or wrong answer, so I'm definitely interested in folks experiences with this.
Archive powered by MHonArc 2.6.16.