12.4 DSL in core providers

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, (https://github.com/chef/chef/blob/master/lib/chef/provider/git.rb#L324, https://github.com/chef/chef/blob/master/lib/chef/provider/execute.rb#L30) 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. https://github.com/poise/application_git/blob/master/lib/poise_application_git/resource.rb and https://github.com/poise/poise-ruby/blob/master/lib/poise_ruby/resources/ruby_execute.rb).

–Noah

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, (https://github.com/chef/chef/blob/master/lib/chef/provider/git.rb#L324, https://github.com/chef/chef/blob/master/lib/chef/provider/execute.rb#L30) 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. https://github.com/poise/application_git/blob/master/lib/poise_application_git/resource.rb and https://github.com/poise/poise-ruby/blob/master/lib/poise_ruby/resources/ruby_execute.rb).

–Noah

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.

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, (https://github.com/chef/chef/blob/master/lib/chef/provider/git.rb#L324, https://github.com/chef/chef/blob/master/lib/chef/provider/execute.rb#L30) 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. https://github.com/poise/application_git/blob/master/lib/poise_application_git/resource.rb and https://github.com/poise/poise-ruby/blob/master/lib/poise_ruby/resources/ruby_execute.rb).

–Noah
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?


Daniel DeLeo

On Jun 29, 2015, at 3:26 PM, Daniel DeLeo dan@kallistec.com wrote:

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, (https://github.com/chef/chef/blob/master/lib/chef/provider/git.rb#L324, https://github.com/chef/chef/blob/master/lib/chef/provider/execute.rb#L30) 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. https://github.com/poise/application_git/blob/master/lib/poise_application_git/resource.rb and https://github.com/poise/poise-ruby/blob/master/lib/poise_ruby/resources/ruby_execute.rb).

–Noah
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 parity.

–Noah

On 6/29/15 3:30 PM, Noah Kantrowitz wrote:

On Jun 29, 2015, at 3:26 PM, Daniel DeLeo dan@kallistec.com wrote:

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, (https://github.com/chef/chef/blob/master/lib/chef/provider/git.rb#L324, https://github.com/chef/chef/blob/master/lib/chef/provider/execute.rb#L30) 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. https://github.com/poise/application_git/blob/master/lib/poise_application_git/resource.rb and https://github.com/poise/poise-ruby/blob/master/lib/poise_ruby/resources/ruby_execute.rb).

–Noah
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 parity.

–Noah

Yeah, I’d like to see more parity between LWRPs and core resources.

However, it is a good point that even without method_missing we’d be
allowing cookbook LWRPs to inject methods into the namespace of all the
core providers.

On Wednesday, July 1, 2015 at 3:50 PM, Lamont Granquist wrote:

On 6/29/15 3:30 PM, Noah Kantrowitz wrote:

On Jun 29, 2015, at 3:26 PM, Daniel DeLeo <dan@kallistec.com (mailto:dan@kallistec.com)> wrote:

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, (https://github.com/chef/chef/blob/master/lib/chef/provider/git.rb#L324, https://github.com/chef/chef/blob/master/lib/chef/provider/execute.rb#L30) 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. https://github.com/poise/application_git/blob/master/lib/poise_application_git/resource.rb and https://github.com/poise/poise-ruby/blob/master/lib/poise_ruby/resources/ruby_execute.rb).

–Noah
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 parity.

–Noah
Yeah, I’d like to see more parity between LWRPs and core resources.

However, it is a good point that even without method_missing we’d be
allowing cookbook LWRPs to inject methods into the namespace of all the
core providers.

Yep, stuff like this is why I want a compromise, either recipe do; end, or just #declare_resource/#build_resource or something.


Daniel DeLeo