Duplicate features

[badgerious]

I'd like to define an FFI feature in a module so it can die gracefully on older puppets, but the question I have is this: Is it better to

A) create a feature at 'puppet/feature/ffi.rb' and  do something like:

Puppet.features.add(:ffi, :libs => ['ffi'])

B) create a feature at 'puppet/feature/my_module.rb' and then:

Puppet.features.add(:my_module, :libs => ['ffi'])

It looks like if two modules have a feature file with the same name, whichever one pluginsyncs first wins.

Poking through modules on the forge, it looks like features are not used terribly often, and it seems unlikely that someone would create a file 'ffi.rb' and then fill it with something other than an :ffi feature, but it is a shared namespace, so I'm curious to know if anyone has any experience that suggests a particular way.

Thanks,
Eric

[Rob Reynolds]

On Sun, Aug 17, 2014 at 8:16 PM, badgerious <badg...@hotmail.com> wrote:

I'd like to define an FFI feature in a module so it can die gracefully on older puppets

This seems reasonable, but how far back are you wanting to support?  We've had FFI included since 3.3.2[1].

[1] https://github.com/puppetlabs/puppet/blob/3.3.2/Gemfile#L54

 

, but the question I have is this: Is it better to

A) create a feature at 'puppet/feature/ffi.rb' and  do something like:

Puppet.features.add(:ffi, :libs => ['ffi'])

B) create a feature at 'puppet/feature/my_module.rb' and then:

Puppet.features.add(:my_module, :libs => ['ffi'])

It looks like if two modules have a feature file with the same name, whichever one pluginsyncs first wins.

It seems more of an explicit namespace would be good.  For option A, that seems like a good thing to add to Puppet proper.

 

Poking through modules on the forge, it looks like features are not used terribly often, and it seems unlikely that someone would create a file 'ffi.rb' and then fill it with something other than an :ffi feature, but it is a shared namespace, so I'm curious to know if anyone has any experience that suggests a particular way.

Thanks,
Eric

--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/fb3c84ca-1bab-4476-9065-35f820b8d19d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Rob Reynolds

Developer, Puppet Labs

Join us at PuppetConf 2014, September 20-24 in San Francisco

Register by September 8th to take advantage of the Final Countdown —save $149!

[badgerious]

Thanks Rob. I guess I'd vote B as well, because, while A may work even with some name collisions, it would be I think very confusing to debug if there were ever a real conflict. As far as how back I want to support, dunno really, I just thought it would be polite to throw a guard in there since it pretty much kills the puppet run if the autoload fails. I think supporting anything in the 3.x.x line is a reasonable thing to shoot for.

Eric

[Rob Reynolds]

On Mon, Aug 18, 2014 at 6:29 PM, badgerious <badg...@hotmail.com> wrote:

Thanks Rob. I guess I'd vote B as well, because, while A may work even with some name collisions, it would be I think very confusing to debug if there were ever a real conflict. As far as how back I want to support, dunno really, I just thought it would be polite to throw a guard in there since it pretty much kills the puppet run if the autoload fails. I think supporting anything in the 3.x.x line is a reasonable thing to shoot for.

Sorry for the confusion, I was just mentioning how far back we've had FFI. A guard is fine.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/ff9766fa-8821-46b7-bbf2-aad19e5e59ef%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.