Easy generators #118
Easy generators #118
Conversation
|
|
||
| Create new cookbooks in this directory with Knife. | ||
|
|
||
| knife cookbook create COOKBOOK |
There was a problem hiding this comment.
Question: (why) are we not encouraging chef generate cookbook NAME?
There was a problem hiding this comment.
We will change them as soon as the rest of the pending workflow RFC gets
merged/we have time.
On Mon, Jul 28, 2014 at 5:30 PM, Claire McQuin notifications@github.com
wrote:
In
lib/chef-dk/skeletons/code_generator/files/default/repo/cookbooks/README.md:
- current_dir = File.dirname(FILE)
- cookbook_path ["#{current_dir}/../cookbooks"]
+Which will set
current_dirto the location of the knife.rb file itself (e.g.~/chef-repo/.chef/knife.rb).
+
+Configure knife to use your preferred copyright holder, email contact and license. Add the following lines to.chef/knife.rb.
+
- cookbook_copyright "Example, Com."
- cookbook_email "cookbooks@example.com"
- cookbook_license "apachev2"
+Supported values for
cookbook_licenseare "apachev2", "mit","gplv2","gplv3", or "none". These settings are used to prefill comments in the default recipe, and the corresponding values in the metadata.rb. You are free to change the the comments in those files.
+
+Create new cookbooks in this directory with Knife.
+
- knife cookbook create COOKBOOK
Question: (why) are we not encouraging chef generate cookbook NAME?
—
Reply to this email directly or view it on GitHub
https://github.com/opscode/chef-dk/pull/118/files#r15500302.
There was a problem hiding this comment.
Cool! Good information to know. :)
|
Super cool. I like the readmes... very delightful. |
|
The readmes are actually part of the other PR - I'm not sure how to have (can you have?) dependent review requests with Github. But this one builds on top of the other PR. |
|
You can PR on a PR but it gets weird quickly. |
|
I liked the terseness of writing: Generator.add_attr_to_context(:thing)Vs: Generator::Context.add_attr(:thing)In particular because it's not just adding to context, but the template helper as well. Happy to change it if you would rather. |
|
Fixed both of Dan's suggestions (public_send and moved add_attr to a method on context) |
Adds ChefDK::Generator.add_attr_to_context, which handles adding instance variables (and optionally their values) to the ChefDK::Generator::Context and ChefDK::Generator::TemplateHelper. This makes writing new generators much easier, because you don't have to be aware of how/when/where the context variables are set up - you can just focus in on the generator you are adding. Additionally, any option added to a generator is dynamically added to the Context and TemplateHelper if it has a value, making the barrier even smaller. One thing to note is that generator options really should either be true/false or have default values that make sense for the generator, or you're liable to get errors. (This is appropriate, I think) While cleaning up the existing context accessors, I noticed that at least one of them (license_description) existed in a template, but was never set anywhere. I implemented the method within the TemplateHelper, so that you can dynamically ask for the correct license description to embedd in a file, including what to comment the license with.
| attr_accessor :copyright_holder | ||
| attr_accessor :email | ||
| attr_accessor :policy_only | ||
| def self.add_attr(name) |
There was a problem hiding this comment.
👍 to the cleanliness, but this definitely needs some docs and @example tags for future developers please 😄
There was a problem hiding this comment.
Yeah - my plan is to write docs on how to write generators easily.
Pick libyaml 0.1.5 in builds.
Depends on PR #117
Adds ChefDK::Generator.add_attr_to_context, which handles adding
instance variables (and optionally their values) to the
ChefDK::Generator::Context and ChefDK::Generator::TemplateHelper. This
makes writing new generators much easier, because you don't have to be
aware of how/when/where the context variables are set up - you can just
focus in on the generator you are adding.
Additionally, any option added to a generator is dynamically added to
the Context and TemplateHelper if it has a value, making the barrier
even smaller. One thing to note is that generator options really should
either be true/false or have default values that make sense for the
generator, or you're liable to get errors. (This is appropriate, I
think)
While cleaning up the existing context accessors, I noticed that at
least one of them (license_description) existed in a template, but was
never set anywhere. I implemented the method within the TemplateHelper,
so that you can dynamically ask for the correct license description to
embedd in a file, including what to comment the license with.