- From: Noah Kantrowitz <
- To: Chef Dev <
- Subject: [chef-dev] Re: Re: 12.4 DSL in core providers
- Date: Mon, 29 Jun 2015 15:30:47 -0700
On Jun 29, 2015, at 3:26 PM, Daniel DeLeo
> On Saturday, June 27, 2015 at 12:57 PM, Lamont Granquist wrote:
>> On 6/26/15 4:21 PM, Noah Kantrowitz wrote:
>>> Throwing this on the mailing list as a reminder since I think I've used
>>> up my quota of tickets lately: It would be nice to move towards adding
>>> the recipe DSL back to Chef::Provider. Currently there are unpleasant
>>> issues when you subclass a non-DSL-using provider and then mix in the DSL
>>> module. Several providers have methods with names matching DSL stuffs,
>>> so if you mix in the DSL such that it comes before the superclass in the
>>> MRO, stuff goes haywire. If the DSL was pulled in earlier in the MRO,
>>> then the "correct" methods would take priority. I can fix this one-off
>>> each time it comes up, but being unable to use the DSL when extending
>>> core classes is something I would love to see in the future (ex.
>> Yeah, in retrospect we shouldn't have pulled the Recipe DSL and should
>> have eliminated method_missing from the Recipe DSL instead. Since we're
>> going down the road of eliminating method_missing from the Recipe DSL,
>> it should probably go back into Chef::Provider.
> I find having the DSL when I don’t want it pretty annoying actually.
> method_missing is really annoying since you get absurd errors for any
> typo’d method name, but the DSL also camps on a lot of domain words so you
> can also invoke it “correctly” on accident as well.
> Is there a compromise that doesn’t suck, like invoking the DSL only inside
> a block or adding just the non-dynamic DSL methods (#declare_resource and
> #build_resource) maybe?
method_missing is being phased out already and will be gone from the DSL in
13. We could certainly put it back in Provider without method_missing too,
since we already burned that compat bridge. Doing in a block is possible (see
also the fused #action context stuff in resources already), but I think it
would be cleaner to find a solution that keeps "real providers" and LWRPs in
Description: Message signed with OpenPGP using GPGMail
Archive powered by MHonArc 2.6.16.