Glad to see that you are taking resolution of infrastructures into
account, that was missing from both librarian and berkshelf. Still,
I’m wondering whether it’s lacking the notion of a node, i.e.:
- infrastructure being a set of nodes with independent dependency graphs.
- within each graph the “users” cookbook must resolve to a unique
version, but across the graphs it could exist in different versions in
the same infrastructure
- ideally this was represented on the filesystem level as well, i.e.
“cookbooks/node-abc/users-1.7.0” along with
"cookbooks/node-xyz/users-1.6.0" for example
I am currently achieving that using berkshelf + the
vagrant-topevel-cookbooks  plugin, which obviously works only if
you use vagrant for describing your infrastructures. However, I could
imagine that a per-node representation of the dependency graph could
be useful for chef-provisioning  as well.
On Wed, Mar 18, 2015 at 1:11 AM, Michael Weinberg email@example.com wrote:
We’re really excited to share a recent Heavy Water Labs project, Batali, a
lightweight cookbook dependency solver that “does one thing well.”
We’ve got a nice write up about it here:
The TL;DR on our rationale for Batali:
Just solves dependencies, no workflow required or supplied, and no repo
Performs least-impact updates by default, so an update doesn’t pull in
Solves for your entire infrastructure, including incompatible dependency
trees for independent nodes/run lists.
The project is hosted here:
Batali is currently in a stable alpha state, and we’re actively using it for
Michael F. Weinberg | Director of Operations
http://heavywaterops.com | @heavywaterops