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

[Andrew Gross < >]

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