[chef-dev] Re: Re: Re: dependency spaghetti

[Peter Donald < >]

On Thu, Oct 3, 2013 at 12:05 PM, Noah Kantrowitz < " target="_blank"> > wrote:

On Oct 2, 2013, at 6:57 PM, Peter Donald < "> > wrote:
> On Thu, Oct 3, 2013 at 9:17 AM, Blake Irvin < "> > wrote:
> For example, the 'java' cookbook includes a 'depends' for the 'windows' cookbook - this means that I'm forced to download the 'windows' cookbook to all of my *nix machines.  Messy at best.
>
> It also tends to pollute the attribute namespace, possibly add all sorts of code via libraries etc. We hit problems with a dependency monkey patching things to broken-ness. Not fun.
>
> Thus we tend strip out all non essential cookbooks from depends flags and add suggests where there is an optional context specific dependency. The context is usually dependent on the environment or features used in the cookbook. i.e. The cookbook when run on ubuntu needs 'apt', while on windows it needs 'windows'. The cookbook needs the authbind cookbook if you are using authbind or the runit cookbook if the init system is set to runit. It then becomes the responsibility of the wrapper cookbook to depend on the required dependencies rather than the library cookbook.
>
> The "add a depends for a any potential dependency" philosophy harks back to earlier patterns of chef usage before wrapper/library cookbook distinctions started to being used when cookbooks tended to be fairly tightly wedded to the initial context of use.

The problem is as we move the community to Berkshelf and tools like it (which is totally the right direction) you can't just edit the upstream cookbooks since you never see them directly. Optional dependencies would help, but the user experience if you are missing an optional cookbook is definitely not great and we'll need some improvements there. The real dream is some kind of declarative way to state when a dependency is needed, but so far I've not seen any proposed way to do that which doesn't veer off into crazytown.

We do enforcement within the cookbook itself. Roughly it is the psychological equivalent of 

raise "Must include cookbook 'mydep' for reason Y" unless run_context.cookbook_collection.values.any? {|c| c.name.to_s == 'mydep' } 

wrapped in a handy little helper like

ensure_cookbook('mydep')

We also go a step further and allow passing in of a recipe that is also included at the same time ala

ensure_cookbook('mydep','mydep::some_recipe')

A little ugly but seems to be relatively useful and it puts the requirement into the code when needed. No need to create a whole capability model for cookbooks to determine when/where features are enabled.

-- 

Cheers,

Peter Donald