Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Proposal for default resource name and DSL #136
You might want to put some mention of the explicit motivating case in here:
In 12.0.0 the provider resolver dealt with ambiguous provider resolution by sorting the classes and then picking the first one which survived various conditions which mean it was lexicographical by class name. In 12.3.0 a warning was added that this was ambiguous and that the user need to set the priority array explicitly. In 12.4.0.rc.2 due to refactoring this changed so that it was last-parsed-class wins which meant that it was (after cookbook loading order) the last lexicographically sorted library file that was parsed, which in the common case of class names and file names matching and the providers in the same cookbook meant that the sort order was reversed.
This directly affects the git cookbook which declares both source and binary providers that provides the
This is a cookbook bug, but its also likely a breaking change since the behavior on upgrade is undelightful. We want to preserve the 12.0.0 sort order behavior in this case and preserve a warning similar to 12.3.0
referenced this pull request
Jun 18, 2015
Summary from rambling on IRC: -1 on this as I would rather see explicit naming. More concretely this also doesn't apply to providers at all, so in all cases those would still need to be explicit when outside the
My preference is to not have a convention that includes branching logic, because the user ends up having to understand and internalize that complexity anyway, but it's also "out of sight, out of mind." If
I think we should just force it to be explicit:
class Foo < Chef::Resource resource_name :foo provides :foo provides :bar, os: :linux end
Since this is all about reducing the typing of
class Foo < Chef::Resource provides :foo, name: true provides :bar, os: :linux end
Borrows from the "name attribute" concept to name the resource after one of the provides lines. Still got to type 'Foo' once and ':foo' once, but I think there's a tradeoff between magic and typing that you hit when you try to reduce duplicated typing to zero -- and magic is bad because you have to hold that magic in your head, and there's already enough stuff to learn about provider and resource resolution.
I also think that even inside of Chef::Resource it should work this. We have some backcompat stuff we have to support with magic based on the class, but that should be confined to Chef::Resource and deprecated.