-
Notifications
You must be signed in to change notification settings - Fork 17
roadmap - usage of strainer #9
Comments
I'm surprised @sethvargo is now recommending against use Strainer to test individual cookbooks. I've been using it no problem at like this and the readme even mentions standalone mode. If this is the case though I'd agree that a Rakefile should be used to achieve similar results. |
@jeremyolliver feel free to @-tag me in these things and I'll leave words. When I originally wrote Strainer, the Chef ecosystem was much less stable. Additionally, CustomInk was using a monolithic Chef repo. Strainer's original purposes was to take a list of cookbook's and it's dependencies and move them into a sandbox for testing. That's it. But then people wanted support for using Strainer inside an individual cookbook. And me, being the youngin' that I was, decided that I should just blindly accept support for such a feature, without considering the repercussions. Then there was support for nested For monolithic Chef repos (where all the cookbooks are in a single directory), Strainer will continue to exist. However, once we get Berkshelf 3 out the door, I'm going to pull the plug on using Strainer inside individual cookbooks. Rake is a far more common tool in the Ruby community and we should leverage it as much as possible. If you look at the new Jenkins cookbook, you'll see that I've used a I'm not really sure what that means for meez. Looks like a cool project, but I actually don't use generators for anything. I spend more time cleaning up files I don't want or trying to figure out which command to specify than if I just made the files myself. So I don't really have any awesome insight to add on that front, but let me know if there's any other way I can help. |
Thanks @sethvargo - I think the deprecation of individual support from strainer is a good call, given the main benefits of directory isolation in a shared repo don't really apply to a single cookbook setup. The main benefit to a generator/bootstrapper (at least to me) is that it kinda saves having to hunt blog posts for the latest toolchain setup each time you write a cookbook - and having some blog posts out of date. I knew enough to know that I wanted berkshelf, test-kitchen, chefspec, and serverspec tests in my new cookbook, but finding meez meant I didn't have to do any plumbing to get it setup. If @paulczar thinks it's a good idea, I might send a PR to migrate this project to a Rakefile, there's probably more documentation changes than anything |
+1 for removing Strainer and migrating to the Rake based approach. |
Actually, after thinking about this again, maybe it would be better to use Thor instead of Rake since we already have that setup for Berkshelf and TK tasks. |
👎 on thor. TK and Berks only have it because of the CLI pieces. I'm trying to pull those out too. |
@sethvargo I'll bow to your greater knowledge, Rake it is then 😄 |
Sounds good. I'm only using Strainer as that is a common patterns on some existing cookbooks I've used. Anyone want to throw together a PR for it ? |
Hi, I've been using meez for the setup of the last cookbook I wrote, and just wanted to bring to your attention that Seth Vargo, the author of strainer is no longer recommending or supporting using strainer to test individual cookbook repo's (just for testing cookbooks kept together in a chef-repo situation with multiple cookbooks in it).
Discussion was at customink/strainer#55 and in fact, removing strainer didn't mean giving up the integration with the given default tools used in meez, the same was achieved with a single Rakefile. See https://github.com/opscode-cookbooks/jenkins/blob/master/Rakefile for an example setup.
It may be worth moving to a similar setup rather than get left behind - in fact I already encountered some issues with the strainer integration (in above ticket)
The text was updated successfully, but these errors were encountered: