On Thursday, October 2, 2014 12:54:06 PM UTC-5, 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. >
I cannot speak to the Puppet implementation issues involved here, but speaking from under my sysadmin hat, I will say that relying on any gems is the *last* thing I want any module I use to do. My systems already have package management under control, thank you, and I do not want gems to complicate that. I'll grant an exception to gems encapsulated in and managed via native packages, but what's the point of that, really? > > 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. > > If a certain module depended on gems, and if, despite my better judgement, I wanted to use it anyway, then the *next* last thing I would want it to do is automatically install gems on my master as part of its own installation. > 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? > > I agree that the Features feature is not suitable for your purpose. Features are not designed or intended for what you want to do. > 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. > You can address the node installation issue via your module implementation. Yes, that makes the module more complicated. > > 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? > > I'm sure I'm in the minority, but I would indeed prefer to receive your module on my master via a native package (i.e. an RPM). Supposing that it were instead delivered via the module tool, I agree that it would be very good if the module metadata could document dependencies on external software such as gems and native applications, and it would be outstanding if the module tool could check those dependencies and maybe even *offer* to install any missing ones. John -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/cbd7bfce-a80a-440a-9e45-18c12165dcb4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
