[chef] Re: Re: Re: Re: Re: LWRP to extend a Chef resource?

[Ranjib Dey < >]

i dont agree that hwrp development will necessarily involve mucking around with internal api (given we dont have a clear understanding of what is internal api anyway). LWRP, like recipes & attributes ,, are instance_evaled. this way of extending has some inherent limitations. You cant do so many things. Testing itself becomes pain (shoutout the seth vargo more adding custom matcher api for lwrps). On contrast, lwrp's does not really stop you using chef internal api, so you have that risk even there.

If you consider the example that was mentioned above, you create the resource in the action method itself. What if your lwrp has multiple actions? will you repeat that code? or create those resources in a commone place (chef calls it load_current_resource). What is you want to support whyrun mode and you want a more meaningful converge_by description instead of all the sub-resources' converge_by description? You cant do these things with lwrp.

I can cite many more examples. Recently we migrated the sumologic cookbook's sumo_source resource (this was a definition earlier) to a standard chef resource. We could not do this with lwrp, because you cant control the resource name with lwrp. with hwrp we could do that, and now we have rewritten the sumo_source without changing any of the integrations or consumers. We were able to keep the usage exactly same.

Its sad that you think we should not reuse chef's internal public api even after 5 years of using and extending it. Any public method from Chef's main domain object is its public facing api, and i'll encourage others to use it. We now have elaborate testing suite that can catch version specific breaking. And I dont know anyone who uses arbitrary chef version (almost all of us uses a specific version, and update/upgrade are tested before hand), chef 11.x minor releases have already proved that legit things can break even within minor release (so we dont have to muck around with internal api to experience the same effect), making it impossible for many of us to update. On contrary i think Chef committers should ensure api compatibility, throw deprecation warning in between introduction of breaking changes (and I know in most cases they do that).   

i really find it bizarre that we see so many recipe with Chef::Recipe.send(:include, AwesomModule::Foo) which is outright breaking encapsulation, and then defend instance_eval style extension instead of  require/subclass etc.

again, i love lwrp , its short, sweet., easy to learn but there are ample reasons to build hwrp. and this is not a rant, but a disagreement that extensions should be limited to the dsl. 

On Wed, Oct 30, 2013 at 8:12 AM, Andrew Gross < " target="_blank"> > wrote:

I agree with Lamont, the main motivation to use HWRP should be to access some of the more traditionally ruby constructions, but not to muck around directly with the internals of other resources.

I often find it useful to use HWRP when I need to use things like begin/rescue and it cannot be done in a library.

On Tue, Oct 29, 2013 at 6:25 PM, Lamont Granquist < " target="_blank"> > wrote:

Also with the HWRP if you subclass a chef resource and go mucking in its internals, you may find yourself rudely busted in a minor release version of Chef.  Most HWRP code that I've seen reuses internal code in ways that make it almost certain that the HWRP will be brittle to changing chef releases.  When using LWRPs you're reusing existing resources via their public APIs and we try our best to keep that stable.

On 10/29/13 11:33 AM, Mike wrote:

Thanks Daniel for the code snippet - that's pretty much the thing I was looking for,a s well as the knowledge that it wasn't currently possible.

Ended up looking like this:

action :install do

  easy_install_package(new_resource.name) do

    options "--index-url None --find-links http://localrepo"

    version new_resource.version

    action :install

  end

end

Thanks to Ranjib for pointing out the HWRP method, but I was trying to keep away from that just yet for this particular concept.

-M

On Tue, Oct 29, 2013 at 11:21 AM, Ranjib Dey < " target="_blank"> > wrote:

i cant think of a straight forward way to do it in lwrp. may be you can have the parent resource as an instance variable (inside the provider) and then use def delegator to pass on the methods etc. you can do the standard sub classing with hwrp easily. All the service providers are derived from a base service resorce/provider, same for pacakges. you can check their code for example

On Tue, Oct 29, 2013 at 8:10 AM, Mike < " target="_blank"> > wrote:

I've been looking in to how I might go about writing something to subclass an existing Chef resource, that already extends another Chef resource.

Case: the easy_install_package resource subclasses the package resource, and adds semantics and behavior specific to easy_install.

I want to further subclass this resource and add some defaults, so that whenever I call mikes_easy_install_package (name is WIP) I get the directives/options I've declared.

Is there a decent example of this anywhere, and my Google-fu is simply failing me today?

Thanks,

-Mike