The following are brief justifications of the foodcritic exceptions being used in the first pass of foodcritic bug-bashing. In most cases we are excluding rules to make the amount of work more manageable for this first pass. In a few cases, the core cookbook team doesn't think that a rule is appropriate for the Opscode community cookbooks.
Ensuring that a cookbook works without a Chef Server is often more work than a simple if statement around a call to search. The READMEs for these cookbooks should clearly state that they currently require a Chef Server and adding conditionals throughout a recipe to also account for this limitation often only serves to clutter the recipe.
In the long run, we welcome better support for chef-solo-style use cases.
This is rather rare in Opscode community cookbooks. However, in the places where it does occur it is typically because of known bugs in the underlying service that prevents the standard service resources from working correctly.
Many Opscode cookbooks ship an array of recipes covering many use cases. These recipes have dependencies that aren't generally needed by the default behavior of the cookbook and including them in metadata would force many users of the default behavior to download dependencies that they do not need.
This is something we are definitely interested in improving moving forward. The following two bugs offer some suggestions about how we might be able to handle depenencies more gracefully in Chef itself:
http://tickets.opscode.com/browse/CHEF-3870
http://tickets.opscode.com/browse/CHEF-3871
We completely agree with this rule. But, for many definitions it can be a lot of work. If you are an experienced cookbook writer, familiar with the specific definition in question, and up for a meatier task, feel free to open a ticket specifically for the conversion and submit a patch. However, if you are just looking to squash as many foodcritic errors as possible, feel free to ignore this and move on for now.
Like FC0015 above, this needs to be fixed for all LWRPs. However it can require substantially more work and experience to fix these issues and is thus out of scope for this first pass.
We disagree with this rule. Inside the Opscode community cookbooks we typically use Ruby conditionals (evaluated at compile time) to branch on platform and version differences. That is, we use a conditional around a single resource to prevent that resource from being in the Resource Collection at all when the resource isn't one we would ever need to manage on the target system. only_if and not_if are used to guard against unnecessary action for resources that are not idempotent by design.
Ultimately passing variables into a template does provide a cleaner, more explicit interface; however, there are cases where you need to pass node attributes. Also, in many cases, the simplicity of using a common node attribute inside a template is worth the tradeoff.