Just to add. If you can remove any gem dependency by reimplementing that functionality inside your own provider or even create some helper code I would try that. There is a section in Nan's book that details how to distribute external helper code inside the module for native types/providers. Its some special folder called PUPPET_X or something (can't remember). If your using open source puppet you could even augment the puppet gemspec to include new runtime dependencies. However, you would also need to host this custom gem and ensure everyone downloads your custom gem instead of the puppet gem from puppet labs/rubygems.org.
I would also consider using omnibus and creating your own distributable packages that contain everything you need to run your puppet environment. This way as long as your system has been bootstrapped with your "management" package you can ensure everything is there to run your custom native type/providers. This would also make it easy to version your cocktail of management gems and packages. Corey On Thursday, October 2, 2014 10:54:06 AM UTC-7, Chris Pitman wrote: > > Hey everyone, > > I'm hoping someone can enlighten me here: Why is it so hard/complicated to > use third party gems when developing a custom provider? It seems to me that > pulling in gems should be priority #1, since it allows providers to > leverage a lot of development already done in the ruby community. > > However, right now it is complicated: > > 1. I have to get my users downstream to install gem dependencies before > using any resources related to the provider. There is no way for me to > annotate the module itself for these dependencies, and no support for > automatically pulling them down. > > 2. "Features" offer very limited capability (as far as I understand), and > are poorly documented. The only documentation is on how to link providers > and types using features, not on how to require ruby libraries. There is no > way for anything other than a type to specify requiring a feature. For > example, what if a provider requires a gem? > > 3. "Features" only protect part of the lifecycle. Even without a feature > present, puppet still attempts to resolve auto-require relationships. This > makes sense based on how things work, but what am I supposed to do if I > need a third party gem there? > > 4. Some gem dependencies need to be present on both the puppet master (in > the master's environment) and on the node. There is no way for me to > transparently take care of this for users. > > So, am I just missing something? Is there some secret hook in the puppet > source that makes dealing with gems better? Should I just start > distributing this provider as a package, and ignore "puppet module", r10k, > etc? Or are there any changes coming down the pipeline that will make this > work better? > > Thanks, > Chris > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/9f2afba5-025c-4bee-ac67-8559de417dd5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
