On Friday, June 29, 2012 1:51:52 AM UTC-5, Brian Gupta wrote:
>
> According to the style guide, "Classes and defined resource types
> must not be defined within other classes."
>
> However looking at
>
> https://github.com/puppetlabs/puppetlabs-nginx/blob/master/manifests/init.pp
> shows that there are a number of other classes defined in class nginx.
>
You are misreading that manifest: it does not define any classes in class
nginx. Rather it *declares* several classes using parameterized class
syntax. "Defining" a class is this:
class foo {
# declare resources
}
"Declaring" a class is this:
class { 'foo':
# parameters, if any
}
or
include "foo"
or
require "foo"
The manifest you referred to does only the latter. I'd argue that it could
and should use "include" for those instead of parametrized class syntax,
but it does not conflict with the style guide point you referenced.
Note, however, that elsewhere the style guide (version 1.1.2) says "*Classes
should generally not declare other classes*," which is a bunch of bologna.
A Puppetlabs employee told me recently that he would have that removed, but
evidently it hasn't happened yet.
As far as I am concerned, classes absolutely *should* declare other classes
wherever they have parse-time dependencies on them, and it's fine for
classes to declare other classes to effect composition. That's no big deal
if you use include/require to declare classes, because classes can be
declared any number of times, anywhere, if you use only those mechanisms.
It runs into trouble if you declare classes using the parametrized-class
syntax, however, as a declaration of that kind produces an error if the
class has already been declared. That has been my biggest objection to
parametrized classes ever since they were introduced.
The style guide's provision makes some sense in the context of a site
driven by a comprehensive ENC responsible for declaring every needed class
at top level, in a suitable order. Use of an ENC in such a way is uncommon
and unwise, however, and it doesn't play nicely with third-party modules.
It's ridiculous to make that a general provision for good style. It does
guard against needing to pass parameters down through multiple layers of
classes to get them to where they're actually needed, but if you avoid
parametrized class syntax (as you should) then that's a non-issue.
> What's the correct pattern? (And why?)
>
Each class and defined type should be defined in its own file, named and
located according to the autoloader's expectations. Note that this does
not prevent using nested namespaces (one of the things you get from
lexically nesting class and defined type definitions inside classes), and
it does not prevent classes and defined types from referring to class
variables of other classes (though they must use qualified names to do so).
Generally speaking, every class should declare all classes on which it has
compile-time dependencies, to the extent that it can do so. Such
dependencies come mostly from referencing variables of other classes or
resources declared by other classes.
Classes may declare other classes on which they do not otherwise have
compile-time dependencies, especially other classes from the same module,
to form pre-composed units that are convenient for users to declare. It is
reasonable and often appropriate to design modules around this strategy.
Parametrized class declaration syntax should be avoided at all costs. In
Puppet 2, that largely neuters parametrized classes (use external data
instead). In Puppet 3 you can provide class parameter values via external
data where default values do not suit (so you're pretty much still using
external data instead, but with a convenient interface).
> Also can someone confirm the following class naming standards.:
> 1) In init.pp, naming the main class associated with that module as
> the same name as that module is best practice and will get applied,
> when someone just does include modulename.
>
Yes. Note also that it is optional to have a main class for the module
(that you can declare via "include 'modulename'") at all.
> 2) For all classes that you want to include from other modules you
> need to name them modulename::classname
>
*All* classes should be named (namespace::)+classname (e.g. mymodule,
mymodule::myclass, mymodule::sub_namespace::myclass). Module main classes,
too, based on the convention that they appear in the top-level namespace.
Modules establish namespaces for other classes within them, and additional
namespaces can be created within those (but don't do that by nesting
classes or definitions inside class definitions).
> 3) Other then option 1, one should avoid just using a simple classname
> inside a module, but rather use modulename::classname. (Some
> additional clarification here would be great.)
>
I would simply say that all classes should be referenced by their
fully-qualified names everywhere. There is no need to distinguish option 1
here, as those classes simple names are also their fully-qualified names.
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/XmaPVZIIBUEJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
