Issue #12843 has been updated by Chris Price.
I would have no qualms with flattening, though I personally do appreciate the visible distinction between the params of the base type and the params of the provider. Even if we flatten it though, I still think that having a new method "newproviderparam()" as opposed to the existing "newparam()" would be valuable for the purposes of generating documentation, etc. ---------------------------------------- Bug #12843: Affirm best practices for provider-specific parameters for package providers https://projects.puppetlabs.com/issues/12843#change-55939 Author: Chris Price Status: Investigating Priority: Normal Assignee: Chris Price Category: package Target version: Affected Puppet version: Keywords: Branch: This pull request: https://github.com/puppetlabs/puppet/pull/521 raised some questions about what is the best way for us to handle parameters for the "package" resource type. (This discussion is probably relevant to other resource types as well.) The gist of it is this: the user needed to add support for a couple of bits of functionality that the pip package providers supports, but that we don't have a meaningful representation for in our existing model for "package". (Namely, the ability to specify multiple "sources" instead of a single source, and the ability to disable the implicit/default "source" of the provider.) Generally, this comes down to a balance between simplicity and consistency of our model, weighed against extensibility for module developers going forward. As I understand it, the current "best practice" is that the "package" resource type definition should be the "one true model"; specific providers should not add new parameters that don't exist on the main "package" type. This would give us consistency in that there was a single well-known place where this type of data is defined / specified. However, it has some drawbacks: 1. there is a real danger that we will continue to find new behaviors that are supported by various individual package providers that we don't have a way of representing, which means that the model will keep growing even though the majority of the provider implementations don't support the majority of the available parameters 2. this implies that new parameters must be added into our model before users can develop modules against them. This will slow down development and also encourage users to come up with less-than-ideal workarounds if we keep them waiting for too long when we are weighing supporting a new parameter. Perhaps a good middle ground would be to have a generic "provider_options" parameter, which would accept a hash as its value. Then, any specific provider could be written to expect whatever implementation-specific arguments that it needed. We could even formalize this by extending the Puppet Ruby DSL with a method like "newproviderparam()" (analagous to the existing "newparam()" method), which provider implementations would be required to use when implementing their support for their custom provider_options. This would allow us to continue to automatically generate documentation--it'd just give us a way to generate more specific documentation for individual providers. It should also give us the ability to easily audit the custom parameters defined by all of the providers occasionally, and if we determine that there is a concept that is appearing frequently enough across multiple providers, we can weigh the option of moving it into the main "package" parameter list. We've already somewhat taken a step in this direction with the "install_options" parameter, but this is currently only used by the MSI provider, and as currently implemented it doesn't give us any means to programmatically generate documentation or inspect its usage across provider implementations. Further, if we decide to move in this direction, I think that a case could be made that we could / should deprecate some of the existing parameters for "package", and move them to this implementation-specific area. Here's a quick audit of the existing parameters for the "package" type: <ul> <li>There are currently 18 documented parameters for the "package" resource type.</li> <li>Of these, only 6 (:ensure, :name, :provider, :responsefile, :source, :status) seem to be reasonably general.</li> <li>Another is deprecated (:type)</li> <li>The remaining 11 seem like they are specific to a very small subset of the providers: <ul> <li>:allowcdrom is only used by apt</li> <li>:adminfile is only used by sun</li> <li>:category is only used by sun and portage (though I could see a case for keeping this one as a general parameter)</li> <li>:configfiles is only used by apt and dpkg</li> <li>:description is only used by sun and portage (though I could see a case for keeping this one as a general parameter)</li> <li>:flavor is only used by openbsd</li> <li>:install_options is only used by msi</li> <li>:instance is only used by rpm</li> <li>:platform is only used by sun</li> <li>:root is only used by sun</li> <li>:vendor is only used by sun and portage</li> </ul> </li> </ul> -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
