Markus Roberts <[email protected]> writes:
[...]
> 1. Ensure that each autoloaded file only contains classes,
> definitions, and nodes whose names match the filename (for example,
> foo/bar.pp should only contain classes such as foo::bar and
> foo::bar::baz).
I would support this, and it keeps the legitimate uses of these non-matching
manifest names working for me. (By which I mean hacks like the following.)
class foo {
# The array is usually split($random_fact, /:/) or something.
foo::helper { ["foo", "bar", "baz"]: }
}
define foo::helper () {
# Do something for each item in the array that isn't easy to express in
# the common bit above.
}
> Proposed Solution III: eliminate the autoloading feature
> --------------------------------------------------------
>
> Do not allow autoloading. Require the user to explicitly import all
> necessary manifest files either directly or indirectly from site.pp.
I would not be happy with this. It would make it crazy-hard to manage a large
scale puppet system.
What looks sensible to me would be to implement option one as a "one major
release" feature, during which time an implementation of option two as a
warning rather than an error.
Then on the next major release crank over to an error, ditch the work-around,
and everyone wins: you can reject the problems (if I understand option 2
right) without having to pay the extra cost to check them every time.
Daniel
--
✣ Daniel Pittman ✉ [email protected] ☎ +61 401 155 707
♽ made with 100 percent post-consumer electrons
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
