Le 24/10/2013 21:05, John Bollinger a écrit :
On Thursday, October 24, 2013 10:39:22 AM UTC-5, Adrien Thebo wrote:
On Thu, Oct 24, 2013 at 12:54 AM, DEGREMONT Aurelien
<aurelien....@cea.fr <javascript:>> wrote:
Le 23/10/2013 17:41, Peter Meier a écrit :
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
It seems that now the recommendation is to have one
file per
class?
Yes it is.
:/
Module manifests will be much more complex with a lot of files
in it.
There will be more files, but you'll still have the same number of
classes and defines. In addition, you can locate classes or
defines by the filename so it means less hunting around. The vast
majority of modules these days are written in this style, so I
don't think that it adds that much complexity.
If no, where puppet will look for foo::a::b class,
(aside from
module/foo/manifest/a/b.pp)?
But you can also have this class in
module/foo/manifest/a.pp
module/foo/manifest/init.pp
if I remember that correctly.
It seems it works that way, at least in 2.7, but I did not
find anything in documentation stating it should work that way.
I'm not confident in this. I'm worried this behaviour will
disappeared in near future and would like to know how long can
I rely on this.
At least it will help us a lot in migrating our manifests from
0.25-style to 2.7+ style...
In fairness, it is probably better to characterize the old style as
0.23 or maybe early 0.24. The current module format and the module
autoloader have been available since at least 0.24.8, as I can attest
from personal experience. Outdated literature may have been more
prevalent in the 0.25 days, but the current module style wasn't even
new any longer then. Although the 'import' function apparently
regressed during the 2.7 series, that's an altogether separate issue,
well separated in time.
This behavior is documented at
http://docs.puppetlabs.com/puppet/2.7/reference/lang_namespaces.html
<http://docs.puppetlabs.com/puppet/2.7/reference/lang_namespaces.html> and
is the supported approach to resource namespacing. It's very
unlikely that this will change at all, let alone in the near
future, and has been the accepted best practice for at least 2 - 3
years.
I think the undocumented behavior Aurélien was concerned about is the
autoloader falling back from my_module/manifests/a/b.pp to
my_module/manifests/a.pp and ultimately to my_module/manifests/init.pp
when trying to load class my_module::a::b. Indeed, it isn't
explicitly documented as far as I can tell; certainly the referenced
document says nothing about it.
In practice, such behavior is necessary to find and load classes that
are lexically nested inside others, so it is at least a matter of
quality of implementation (a win) that the autoloader in fact does
exhibit that behavior. Nevertheless, I think Aurélien is right to be
wary, especially if class nesting ever moves from disfavor to
deprecation, on a path to ultimate removal. Moreover, I think it is
especially risky to rely on that fallback behavior to load classes
that are not lexically nested, ala
my_module/manifests/foo.pp:
----
class my_module::foo {
}
class my_module::foo::bar {
}
At present, if the autoloader looks for my_module::foo::bar in
my_module/manifests/foo.pp then I don't think it matters whether class
my_module::foo::bar is expressed in nested or unnested form. However,
I would account that a parser implementation detail. For instance, it
could be that a future iteration of the parser will attempt to
optimize class loading by stopping the parse of
my_module/manifests/foo.pp when it reaches the closing brace of class
my_module::foo. If that happened, then class my_module::foo::bar in
my example would suddenly become invisible.
You totally catch my concerns!
What could we expect from that in the future?
Aurélien
--
You received this message because you are subscribed to the Google Groups "Puppet
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/526FDCD3.1020304%40cea.fr.
For more options, visit https://groups.google.com/groups/opt_out.
