Proposal: move Chef resources out of Chef::Resource

gistfile1.md

Provider location proposal (File.exists?)

This proposal attempts to solve two problems:

• The fact that it is hard to create Resources and Providers outside the Chef:: namespace
• The fact that classes in the Chef::Resource and Chef::Provider namespace (like File) make it harder to write providers (calling File.exists? fails because it grabs Chef::Provider::File instead of ::File)

Easy Outside Provider Declarations

All resources will need to declare what they provide with the "register_resource" declaration, which will be extended with the ability to specify the Provider class.

class Blah::Resource::ArmAndHammer < Chef::Resource
  register_resource 'baking_soda', Blah::Provider::ArmAndHammer
end

If the resource name is not specified, it will be inferred from the class name:

class Blah::Resource::ArmAndHammer < Chef::Resource
  register_resource Blah::Provider::ArmAndHammer
end

If the Provider class is not specified, it will look to see if the Resource class is under a directory named "Resource", and look for a Provider class with the same name in the corresponding Provider class (in this case, Blah::Resource::MyResource will have a default provider Blah::Provider::MyResource).

class Blah::Resource::ArmAndHammer < Chef::Resource
  register_resource 'arm_and_hammer'
end

If the class is in a subclass of Chef::Resource and exists in <any namespace>::Resource, it will automatically get a standard_resource declaration with no parameters, so there is no decoration needed.

If two resources provide the same thing on the same platform, the winner is undefined.

Move LWRPs Out of Chef::

LWRPs are presently housed in Chef::Resource and Chef::Provider. We will add them into the "ChefLWRP" module (see this line and add a "provides" directive to point them at the right place.

Move Standard Resources Out of Chef::Resource

Once the former is done, all Chef standard resources and providers will move from Chef::Provider and Chef::Resource to Chef::Core::Provider and Chef::Core::Resource.

👍

What do you mean by removing https://github.com/opscode/chef/blob/master/lib/chef/resource/lwrp_base.rb#L56 ? I don't think the classes should be anonymous, because error messages get pretty confusing, like no method "foo" for <Class:0xblahblah>:0xblahblah. We can just create a custom namespace for this purpose, like ChefLWRPNamespace or whatever.

Also, I'm on the fence about whether explicit provider names should be required if standard namespacing is followed, e.g., SomeConstant::Resource::ThisThing and SomeConstant::Provider::ThisThing.

Aside from that I'm on board with the general ideas. I think it makes sense to look at a variety of syntaxes but that can wait for implementation.

The existing behavior would be backwards compatible with this change? (ie: are we saying everyone gets to re-write?)

Yeah, i think I'm +1 on ChefLWRP::FooBarBaz rather than Class:0xblahblahblah

Can you dynamically find the subclasses of Chef::Resource and construct a list of those and map them based on the terminal class and get rid of the need for 'provides'?

Yep, if your class lives in Chef::Resource, you get an automatic "provides" to preserve existing behavior. (Adding that note in there now.) Everything should be backwards compatible except that you can't open up the Chef resources with Chef::Resource::File anymore, you'd have to find them in the new place.

I'm cool with putting LWRPs in a namespace :)

I'm actually pretty cool with Dan's proposal, actually. If you declare a subclass of Chef::Resource inside ::Resource, it will automatically get a provides. That would preserve backcompat and make it maximally easy to move classes over!