Use of private in module skeleton

[Gareth Rushgrove]

Hey all

I'd love some feedback on this PR, which adds the private function to
the puppet-module-skeleton that a bunch of people use.

https://github.com/garethr/puppet-module-skeleton/pull/43

A few people commented on Twitter and it's prety much 50/50.

https://twitter.com/garethr/status/535526875477839872

And I'm on the fence too. Any thoughts?

Gareth

--
Gareth Rushgrove
@garethr

devopsweekly.com
morethanseven.net
garethrushgrove.com

[Felix Frank]

On 11/22/2014 01:22 PM, Gareth Rushgrove wrote:
> Hey all
>
> I'd love some feedback on this PR, which adds the private function to
> the puppet-module-skeleton that a bunch of people use.
>
> https://github.com/garethr/puppet-module-skeleton/pull/43
>
> A few people commented on Twitter and it's prety much 50/50.
>
> https://twitter.com/garethr/status/535526875477839872
>
> And I'm on the fence too. Any thoughts?
>
> Gareth

+1 for helping module authors help their users avoid shooting their own
feet.

That's what this is about, right?

Cheers,
Felix

[Wil Cooley]

On Nov 22, 2014 4:22 AM, "Gareth Rushgrove" <gar...@morethanseven.net> wrote:

> I'd love some feedback on this PR, which adds the private function to
> the puppet-module-skeleton that a bunch of people use.
>
> https://github.com/garethr/puppet-module-skeleton/pull/43

...

> And I'm on the fence too. Any thoughts?

As a general principle, I'm not crazy about not being able to use the x::install or x::service classes independent of the main class or whatever the "expected" interface is. x::config or auxiliary subclasses I could see.

Being able to use the subclasses is an important feature for migrating to using the module, either from an unmanaged system, a different module or even a different configuration management tool.

For example, my work environment is a legacy Cfengine shop and we still have quite a number of  EL5 systems co-managed with Cfengine[1]. As I add the ability to manage some service in Puppet, I can easily do so for new, pure-Puppet systems. But for systems managed originally w/Cfengine, I might not want to redo the configuration in the way that it's done with the Puppet module, but I can at least switch the service and package portions to using Puppet.

Maybe this is just another facet of my belief in "don't be a proprietorial asshole with data" and my preference for OO languages that have no "private" concept, only naming conventions.

[1]. I have a script that reads /var/lib/puppet/classes.txt and makes Cfengine classes by prepending "puppet_" and transforming "::" to underscores. Then I litter the legacy Cfengine with !puppet_x_service or whatever.

[Eric Shamow]

+1 here as well.

My choice of Puppet has always been based on the default behavior guiding users who don’t know better toward better patterns.

In the end they can modify the template if they have unusual needs, but as Felix says, we should set them up to do the right thing.

-Eric

-- 
Eric Shamow
Sent with Airmail

--
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/5470F145.4090604%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

[Henrik Lindberg]

If they are creating classes that should be visible to others, they can
just remove the private declaration.

A word of warning here. In puppet 4.0.0 the word "private" is reserved
since the concept of being private is
going to be moved to the language. The function called "private" must
therefore be renamed.

- henrik


--

Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/