1 line
10 KiB
JSON
1 line
10 KiB
JSON
{"name":"poise","version":"2.8.1","description":"Helpers for writing extensible Chef cookbooks.","long_description":"# Poise\n\n[](https://travis-ci.org/poise/poise)\n[](https://rubygems.org/gems/poise)\n[](https://supermarket.chef.io/cookbooks/poise)\n[](https://codecov.io/github/poise/poise)\n[](https://gemnasium.com/poise/poise)\n[](https://www.apache.org/licenses/LICENSE-2.0)\n\n## What is Poise?\n\nThe poise cookbook is a set of libraries for writing reusable cookbooks. It\nprovides helpers for common patterns and a standard structure to make it easier to create flexible cookbooks.\n\n## Writing your first resource\n\nRather than LWRPs, Poise promotes the idea of using normal, or \"heavy weight\"\nresources, while including helpers to reduce much of boilerplate needed for this. Each resource goes in its own file under `libraries/` named to match\nthe resource, which is in turn based on the class name. This means that the file `libraries/my_app.rb` would contain `Chef::Resource::MyApp` which maps to the resource `my_app`.\n\nAn example of a simple shell to start from:\n\n```ruby\nrequire 'poise'\nrequire 'chef/resource'\nrequire 'chef/provider'\n\nmodule MyApp\n class Resource < Chef::Resource\n include Poise\n provides(:my_app)\n actions(:enable)\n\n attribute(:path, kind_of: String)\n # Other attribute definitions.\n end\n\n class Provider < Chef::Provider\n include Poise\n provides(:my_app)\n\n def action_enable\n notifying_block do\n ... # Normal Chef recipe code goes here\n end\n end\n end\nend\n```\n\nStarting from the top, first we require the libraries we will be using. Then we\ncreate a module to hold our resource and provider. If your cookbook declares\nmultiple resources and/or providers, you might want additional nesting here.\nThen we declare the resource class, which inherits from `Chef::Resource`. This\nis similar to the `resources/` file in an LWRP, and a similar DSL can be used.\nWe then include the `Poise` mixin to load our helpers, and then call\n`provides(:my_app)` to tell Chef this class will implement the `my_app`\nresource. Then we use the familiar DSL, though with a few additions we'll cover\nlater.\n\nThen we declare the provider class, again similar to the `providers/` file in an\nLWRP. We include the `Poise` mixin again to get access to all the helpers and\ncall `provides()` to tell Chef what provider this is. Rather than use the\n`action :enable do ... end` DSL from LWRPs, we just define the action method\ndirectly. The implementation of action comes from a block of recipe code\nwrapped with `notifying_block` to capture changes in much the same way as\n`use_inline_resources`, see below for more information about all the features of\n`notifying_block`.\n\nWe can then use this resource like any other Chef resource:\n\n```ruby\nmy_app 'one' do\n path '/tmp'\nend\n```\n\n## Helpers\n\nWhile not exposed as a specific method, Poise will automatically set the\n`resource_name` based on the class name.\n\n### Notifying Block\n\nAs mentioned above, `notifying_block` is similar to `use_inline_resources` in LWRPs. Any Chef resource created inside the block will be converged in a sub-context and if any have updated it will trigger notifications on the current resource. Unlike `use_inline_resources`, resources inside the sub-context can still see resources outside of it, with lookups propagating up sub-contexts until a match is found. Also any delayed notifications are scheduled to run at the end of the main converge cycle, instead of the end of this inner converge.\n\nThis can be used to write action methods using the normal Chef recipe DSL, while still offering more flexibility through subclassing and other forms of code reuse.\n\n### Include Recipe\n\nIn keeping with `notifying_block` to implement action methods using the Chef DSL, Poise adds an `include_recipe` helper to match the method of the same name in recipes. This will load and converge the requested recipe.\n\n### Resource DSL\n\nTo make writing resource classes easier, Poise exposes a DSL similar to LWRPs for defining actions and attributes. Both `actions` and\n`default_action` are just like in LWRPs, though `default_action` is rarely needed as the first action becomes the default. `attribute` is also available just like in LWRPs, but with some enhancements noted below.\n\nOne notable difference over the standard DSL method is that Poise attributes\ncan take a block argument.\n\n#### Template Content\n\nA common pattern with resources is to allow passing either a template filename or raw file content to be used in a configuration file. Poise exposes a new attribute flag to help with this behavior:\n\n```ruby\nattribute(:name, template: true)\n```\n\nThis creates four methods on the class, `name_source`, `name_cookbook`,\n`name_content`, and `name_options`. If the name is set to `''`, no prefix is applied to the function names. The content method can be set directly, but if not set and source is set, then it will render the template and return it as a string. Default values can also be set for any of these:\n\n```ruby\nattribute(:name, template: true, default_source: 'app.cfg.erb',\n default_options: {host: 'localhost'})\n```\n\nAs an example, you can replace this:\n\n```ruby\nif new_resource.source\n template new_resource.path do\n source new_resource.source\n owner 'app'\n group 'app'\n variables new_resource.options\n end\nelse\n file new_resource.path do\n content new_resource.content\n owner 'app'\n group 'app'\n end\nend\n```\n\nwith simply:\n\n```ruby\nfile new_resource.path do\n content new_resource.content\n owner 'app'\n group 'app'\nend\n```\n\nAs the content method returns the rendered template as a string, this can also\nbe useful within other templates to build from partials.\n\n#### Lazy Initializers\n\nOne issue with Poise-style resources is that when the class definition is executed, Chef hasn't loaded very far so things like the node object are not\nyet available. This means setting defaults based on node attributes does not work directly:\n\n```ruby\nattribute(:path, default: node['myapp']['path'])\n...\nNameError: undefined local variable or method 'node'\n```\n\nTo work around this, Poise extends the idea of lazy initializers from Chef recipes to work with resource definitions as well:\n\n```ruby\nattribute(:path, default: lazy { node['myapp']['path'] })\n```\n\nThese initializers are run in the context of the resource object, allowing\ncomplex default logic to be moved to a method if desired:\n\n```ruby\nattribute(:path, default: lazy { my_default_path })\n\ndef my_default_path\n ...\nend\n```\n\n#### Option Collector\n\nAnother common pattern with resources is to need a set of key/value pairs for\nconfiguration data or options. This can done with a simple Hash, but an option collector attribute can offer a nicer syntax:\n\n```ruby\nattribute(:mydata, option_collector: true)\n...\n\nmy_app 'name' do\n mydata do\n key1 'value1'\n key2 'value2'\n end\nend\n```\n\nThis will be converted to `{key1: 'value1', key2: 'value2'}`. You can also pass a Hash to an option collector attribute just as you would with a normal attribute.\n\n## Debugging Poise\n\nPoise has its own extra-verbose level of debug logging that can be enabled in\nthree different ways. You can either set the environment variable `$POISE_DEBUG`,\nset a node attribute `node['POISE_DEBUG']`, or touch the file `/POISE_DEBUG`.\nYou will see a log message `Extra verbose logging enabled` at the start of the\nrun to confirm Poise debugging has been enabled. Make sure you also set Chef's\nlog level to `debug`, usually via `-l debug` on the command line.\n\n## Upgrading from Poise 1.x\n\nThe biggest change when upgrading from Poise 1.0 is that the mixin is no longer\nloaded automatically. You must add `require 'poise'` to your code is you want to\nload it, as you would with normal Ruby code outside of Chef. It is also highly\nrecommended to add `provides(:name)` calls to your resources and providers, this\nwill be required in Chef 13 and will display a deprecation warning if you do\nnot. This also means you can move your code out of the `Chef` module namespace\nand instead declare it in your own namespace. An example of this is shown above.\n\n## Sponsors\n\nThe Poise test server infrastructure is generously sponsored by [Rackspace](https://rackspace.com/). Thanks Rackspace!\n\n## License\n\nCopyright 2013-2016, Noah Kantrowitz\n\nLicensed under the Apache License, Version 2.0 (the \"License\");\nyou may not use this file except in compliance with the License.\nYou may obtain a copy of the License at\n\nhttp://www.apache.org/licenses/LICENSE-2.0\n\nUnless required by applicable law or agreed to in writing, software\ndistributed under the License is distributed on an \"AS IS\" BASIS,\nWITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.\nSee the License for the specific language governing permissions and\nlimitations under the License.\n","maintainer":"Noah Kantrowitz","maintainer_email":"noah@coderanger.net","license":"Apache-2.0","platforms":{"aix":">= 0.0.0","amazon":">= 0.0.0","arch":">= 0.0.0","centos":">= 0.0.0","chefspec":">= 0.0.0","debian":">= 0.0.0","dragonfly4":">= 0.0.0","fedora":">= 0.0.0","freebsd":">= 0.0.0","gentoo":">= 0.0.0","ios_xr":">= 0.0.0","mac_os_x":">= 0.0.0","nexus":">= 0.0.0","omnios":">= 0.0.0","openbsd":">= 0.0.0","opensuse":">= 0.0.0","oracle":">= 0.0.0","raspbian":">= 0.0.0","redhat":">= 0.0.0","slackware":">= 0.0.0","smartos":">= 0.0.0","solaris2":">= 0.0.0","suse":">= 0.0.0","ubuntu":">= 0.0.0","windows":">= 0.0.0"},"dependencies":{},"recommendations":{},"suggestions":{},"conflicting":{},"providing":{},"replacing":{},"attributes":{},"groupings":{},"recipes":{},"source_url":"https://github.com/poise/poise","issues_url":"https://github.com/poise/poise/issues","chef_version":[["< 14",">= 12"]],"ohai_version":[]} |