berkshelf/berkshelf — pull request #1198 by KAllan357 (2014-05-10 00:15:45+00:00)
Title: Skip cached cookbooks missing their name attributes instead of failing

For as long as [CHEF-3490](https://tickets.opscode.com/browse/CHEF-3490) is a thing, it is my opinion that berkshelf should not fail when there exists a cached cookbook that is missing its name attribute.

In our scenario, we have written an estimated 75 cookbooks, and migrating them to use Berkshelf 3 will be an ongoing task. If my development environment (or CI server) has a mix of BS 2 and 3 cookbooks, I'd expect to have many cookbooks that are somewhere between "poopy" and "awesome" in terms of quality.

When I go to execute a `berks install` in a mixed environment like this, I currently get errors like the following:

```
Ridley::Errors::MissingNameAttribute: The metadata at '/Users/kallan/src/berkshelf/spec/tmp/cbstore_rspec/foo-3.0.1'
does not contain a 'name' attribute. While Chef does not strictly enforce this requirement,
Ridley cannot continue without a valid metadata 'name' entry.
```

*Regardless of whether or not my cookbook depends on these bad cookbooks, I receive a failure*.

At the moment, any cookbooks cache that is tainted by one of these cookbooks will fail every berkshelf 3 run on that machine. You either `rm -rf` your cookbooks directory, delete the bad cookbook from your Chef server, or release a new version of the old cookbook with a shiny new name attribute. Ultimately, you still have to `rm -rf` the bad cookbook because its still sitting on your disk, and breaking `berks install`.

Another annoying part is that your bad cookbooks fail one-at-a-time. Deleting just one broken cookbook from your disk might not get berkshelf working again - there may be more bad cookbooks that it just never got to parse because of the raised exception.

What do you think? @reset @ivey @sethvargo