librarian-chef nukes work

[tenaciousRas]

The recursive nature of librarian-chef's search for Cheffile causes it to overwrite a cookbook's current working (development) directory. This problem is exposed when using kitchen-test's local ./cookbooks folder dependency resolution in a cookbook contained in a project using librarian-chef.

It seems easy to imagine mistakes in CI implementation that could lead to disastrous builds. If this is an intended "feature" then it should be a non-default behavior.

platform:

• ubuntu 16.04
• librarian-0.1.2
• librarian-chef-0.0.4

scenario:

• create a working folder foo-project/cookbooks
• create a stub Cheffile with minimal dependencies in foo-project/cookbooks
• create a new stub cookbook in foo-project/cookbooks/my-book
• create a dependencies folder foo-project/cookbooks/my-book/cookbooks. This folder is used by kitchen-test as an option for uploading cookbook dependencies to a chef node. This happens to be the only method of kitchen-test dependency resolution my platform seems to work with at the moment, for whatever reason(s).
• execute librarian-chef install

expected:

• to not lose the current working directory, or
• a prompt that warns the user before losing the CWD

actual:

• current working directory is lost. librarian-chef attempts to re-install dependencies in foo-cookbook/cookbooks. As a result the folder foo-project/cookbooks/my-book/cookbooks is lost. All work is lost without warning.

workaround:

• Move development of custom cookbooks to a parent folder of foo-project/ to avoid mistakes. I suppose one must also search the entire parent directory tree for non-existence of any Cheffile instances also?
• Use librarian-chef install --path [full path to cookbooks folder] in this scenario with kitchen-test.