Re: What's the story about modules that need utility code?
Jo Rhett <jrhett <at> netconsonance.com>
2012-06-06 22:14:38 GMT
Hi, Jeff. I'm glad to see you raising this issue. I'd like to add one more point to your query: 'libraries'
versus 'classes'. Right now the code in $modulepath often serves two very different needs:
classes == where class = group, where the node definition might look like this:
# install and configure a web server
class { 'webserver': }
And then you have functional classes, which operate more like libraries and are re-used often and
differently, and spread throughout other modules:
sysctl::conf {
"net.core.rmem_max": value => 16777216;
"net.core.wmem_max": value => 16777216;
}
I feel somewhat strongly that the puppet ecosphere would be easier to manage and document if these two very
different types of uses were in different places.
On Jun 6, 2012, at 12:44 PM, Jeff McCune wrote:
> We're struggling a bit to come up with a good story around the
> following scenario.
>
> Imagine you're a relatively new-to-puppet and new-to-ruby person who
> is writing a Puppet Module that contains ruby code. A type and
> provider, custom Facter fact, or new puppet subcommand using faces are
> all good examples.
>
> When you're in this situation and you find yourself in need of a place
> to put some code you've written that will be used by multiple things,
> what story should we tell about where to put it? A concrete example
> is a class you've written to display progress bars. More than one
> Puppet face action may need this class and you don't want to duplicate
> code by copying the class into each action.
>
> The proposal in #11419 [1] is to put utility code inside of the
> Puppet::Modules namespace. The reasoning is that when you're in this
> situation your first intuition is probably to put it somewhere inside
> of Puppet. We don't have a place today, so if you look you might
> decide to put your utility code in Puppet::Util. Puppet already uses
> this namespace quite a bit though, so the potential for conflicts and
> monkey patching is high.
>
> Daniel points out Puppet::Modules doesn't actually fix the problem,
> two puppet modules may still declare Puppet::Modules::ProgressBar and
> fight with each other. The idea he has is to follow the Ruby
> convention of putting it somewhere else in the global namespace. My
> concern here is that the story isn't very opinionated and it may not
> be clear to a new person that a file path of lib/puppet shouldn't
> really be declaring a namespace of ProgressBar at the top level. By
> ruby conventions this constant should live in lib/progress_bar.rb.
>
> If you've read this far, could you provide any concrete examples of
> utility code you've written, where you put it, and how you came to
> decide to put it there?
>
> No matter what we decide about #14149 we're going to clearly document
> the story at http://docs.puppetlabs.com/ This email is mainly aimed
> at trying to figure out what the story should be.
>
> Any thoughts or comments would be greatly welcomed.
>
> [1] http://projects.puppetlabs.com/issues/14149
>
> Thanks,
> -Jeff
>
> --
> You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
> To post to this group, send email to puppet-dev <at> googlegroups.com.
> To unsubscribe from this group, send email to puppet-dev+unsubscribe <at> googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
>
--
Jo Rhett
Net Consonance : net philanthropy to improve open source and internet projects.
--
--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To post to this group, send email to puppet-dev <at> googlegroups.com.
To unsubscribe from this group, send email to puppet-dev+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
RSS Feed