Issue #2053 has been updated by Andrew Parker.
Abay C wrote:
> in modules/foo/bar/ted.pp
>
> define foo::bar::ted(){ code}
> define private(){more code}
>
> _________________
> I have tested that private is not available as private OR foo::private OR
> foo::bar::private OR foo::bar::ted::private to any code that's not part of
> the module foo.
> (3.0.2)
>
You can get to private by doing:
<pre>
foo::bar::ted { "pull in the .pp file": }
private { "now everything in it is available": }
</pre>
You won't be able to get to `private` initially. However, once that `.pp` file
that it is contained in is loaded, which would normally by done via the
autoloader, then `private` has been defined and can be used.
> This is a good thing. Why would you consider removing it?
> particularly since the DSL does not even have any looping constructs or
> iterations.
>
> I dont want manifest writers using my module internals to hack out a quick
> result when I dont explicitly provide for it. The burden of every
> define/class doing something valuable that can be used independently is
> simply wayy too high.
>
Being able to mark things private to a module would probably be a good feature.
As you say, having access control to better create encapsulation greatly
improves the maintainability of modules, but this doesn't provide that. What
this is is a shortcut for typing names, which seems to cause confusion
sometimes about what will actually get loaded.
--------------------
I tested that you can get to `private` by creating
`modules/testing/manifests/something.pp` that contains
<pre>
define testing::something() {
notify { "testing::something": }
}
define private() {
notify { "private": }
}
</pre>
which when I run `puppet apply -e "testing::something { hmm: } private { oops:
}"` produces
<pre>
Notice: private
Notice: /Stage[main]//Private[oops]/Notify[private]/message: defined 'message'
as 'private'
Notice: testing::something
Notice:
/Stage[main]//Testing::Something[hmm]/Notify[testing::something]/message:
defined 'message' as 'testing::something
Notice: Finished catalog run in 0.05 seconds
</pre>
----------------------------------------
Bug #2053: Relative namespacing of class/define names results in big surprises
https://projects.puppetlabs.com/issues/2053#change-82346
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.
