Issue #2053 has been updated by John Bollinger.
It seems to me that the issue is not so much relative name resolution, but the
fact that Puppet is so aggressive about trying to find a relative match. I
think it's right and proper to support name resolution relative to the
*current* scope -- it makes sense and it's easy to understand. The problem is
really with trying to resolve names against parent scopes other than the top
scope.
Consider:
class my_module::foo {
notify { 'I am ::my_module::foo': }
}
class foo {
notify { 'I am ::foo': }
}
class my_module {
include 'foo'
}
Is it not reasonable for the author to expect that class my_module is declaring
class ::my_module::foo, rather than class ::foo?
Or indeed, Puppet still supports lexical class containment. If I write
class foo {
notify { 'I am ::foo': }
}
class my_module {
class foo {
notify { 'I am ::my_module::foo': }
}
include foo
}
then I would be inclined expect that class ::my_module::foo is the one declared.
On the other hand, I agree with the OP that it is strange, surprising, and
generally unhelpful for Puppet to attempt to resolve relative names against
parent intermediate scopes. The nagios example is particularly perverse, as it
is never useful for a class to declare itself.
I suggest, therefore, that instead of removing relative name resolution
altogether, its behavior be modified. When Puppet attempts to resolve a
relative name, it should consider two scopes (only): the local scope and the
top scope. This will save a lot of the code that complete removal of relative
name resolution would break, while still making relative name resolution a lot
less surprising.
----------------------------------------
Bug #2053: Relative namespacing of class/define names results in big surprises
https://projects.puppetlabs.com/issues/2053#change-86820
Author: Lawrence Ludwig
Status: Accepted
Priority: Normal
Assignee: Lee Lowder
Category: modules
Target version:
Affected Puppet version: 0.24.7
Keywords: telly deprecation modules classes namespaces names
Branch:
Due to Puppet's relative namespacing of class names, `include bar` does not
mean "declare class `bar`." It actually means "try to declare class `<current
namespace>::bar`, class `<parent of current namespace>::bar`, and so on,
declaring class `bar` only as a last resort."
class bar {
notice("From class bar")
}
class foo::bar {
notice("From class foo::bar")
}
class foo {
include bar
}
include foo
This is maximally surprising, especially considering the prevalence of things
like:
class apache::nagios {
include nagios # joke's on you, because this just includes apache::nagios
again
}
(Test code from original report: <http://pastie.org/409446>)
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
"Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
