Last week I was investigating solutions for retrying IPC/RPC operations in a provider I'm working on and discovered that the puppetlabs-aws module does exactly what I was looking for with the retries gem. I believe the typical pattern for a provider to require a gem is to declare a new feature (for the gem) and then confine the provider to that feature. This means that I'd need to duplicate the :retries feature from puppetlabs-aws into my module since there's no [desired] module level dependency. I'm concerned that it's "asking for trouble" to have multiple module defining, and possibly redefining, the same feature.
Options I've considered: 1. Essentially, do nothing and gamble that if multiple modules in the same environment redundantly define the same feature, nothing bad happens. 2. Modules adopt a convention to namespace features in some way to avoid collisions. Ie, `:retires` becomes `:aws_retires` or pedantically `:puppetx_aws_retires`. 3. Add new confine functionality such that a feature is no longer needed to place a dependency on a gem. Possibly using Puppet::Util::Feature.load_library independently of the rest of the features subsystem. 4. Factor the `:retries` feature out into it's own module, perhaps with a DSL class to handle installation of the gem. 5. Add a new confine type that auto-creates a feature for each lib dependency. I'm sure there are other possible solutions that I have missed. Of these, I suspect \3 is most robust solution. It would also be the most disruptive. \4 would be a fast and cheap solution but I dislike the prospect of trivial dependency sprawl. There probably should be some sort of guidelines established along the lines of \2, if the usage of features in general grows in popularity, but I don't feel its a good solution to duplicate features. It only insures that duplicate features have different names. \5 doesn't completely solve the problem but it does reduce the possibility of conflicting feature definitions and removes the need for boilerplate features in modules. It also appeared to have fairly low implementation complexity so I went ahead and created a module for it. https://github.com/jhoblitt/puppet-confinelibs Using that module, the providers in puppetlabs-aws could declare confine libs: ["retries", "aws-sdk-core"] and the :aws & :retries features would be unnecessary. I'd like to hear others thoughts on the best solution here before I push anything to the forge. Cheers, -Josh -- -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/553DD6FD.1070007%40hoblitt.com. For more options, visit https://groups.google.com/d/optout.