Issue #19561 has been updated by Anthony Ryan. Status changed from Needs More Information to Needs Decision Assignee changed from Anthony Ryan to Rob Nelson
To provide a concrete example, I maintain a replacement for the default portage.rb provider that adds support for use flags, keywords and slots. To support these features it was necessary to add additional parameters to the package type. I added a handful of extra parameters that were not normally included in the package type so they could be used like so: https://github.com/whatbox/PortageGT/blob/master/USAGE.md#keywords The only way I could achieve this syntax was to overwrite the package type, adding in the parameters I needed, as shown here: https://github.com/whatbox/PortageGT/blob/master/lib/puppet/type/package.rb This has an obvious problem, my provider works with multiple versions of puppet but we have to copy the /lib/puppet/type/package.rb file from one specific version of puppet for modification. Because this file hasn't changed much it hasn't proven to be an issue yet, but there remains a threat of bugs occurring as a result of mismatched the puppet version running with the version that file was based off of. What I am proposing here is rather than replacing the entire type as the only way to add a parameter to an existing type is instead it should be possible to simply extend an existing type. The reason I mentioned install_options and the MSI provider was at the time of this ticket being created, that was the only default provider that used install_options. Given there were parameters being added to the package type that were only being implemented by one or two providers seemed like a clear indication that they were not a part of a package type as much as those specific providers. What I would like to see most is the availability of newparam() within the provider rather than the type definition only. Having access to that method within the provider would allow each provider to cater better to it's specific environment without cluttering the package type as a whole. newparam(:allowcdrom) could be moved from the package type to within the apt provider, as that's the only context it ever makes sense in. newparam(:flavor) could be moved to the OpenBSD provider. newparam(:slot) can be added to a portage provider like the one I maintain. Individual providers could have better package name validation by overwriting newparam(:name), as they'll all have more specialized knowledge of what they accept. ---------------------------------------- Feature #19561: Providers should be able to extend the type they implement https://projects.puppetlabs.com/issues/19561#change-98342 * Author: Anthony Ryan * Status: Needs Decision * Priority: Normal * Assignee: Rob Nelson * Category: provider * Target version: * Affected Puppet version: * Keywords: type provider extending * Branch: ---------------------------------------- Currently, the only way to extend a core type, such as the "package" type when defining a provider is to overwrite the original type, adding in newparams()'s and various attributes. It should be possible to achieve this using only the provider class. This will resolve issues where parameters are needed in a type for a single provider, such as install_options in the MSI provider. Additionally it would help allow providers to allow advanced functionality in a more future-proof way, inheriting changes to the core type with version changes. -- 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 unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/groups/opt_out.
