On Tuesday, October 29, 2013 11:05:39 AM UTC-5, Aurélien Degrémont wrote:
>
> Le 24/10/2013 21:05, John Bollinger a écrit :
>
[...]
>
>
> 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?
>
>
I do not represent PuppetLabs, but I predict that the autoloader's current
fallback behavior will be retained more or less as-is at least into the
mid-term future. Nevertheless, I recommend that you do plan to transition
to the recommended form of one class or definition per file, because the
future for that arrangement seems a lot more certain. Completing such a
transition is not urgent, but perhaps it would be wise to establish
maintenance and development policies that will drive you through it over
time. For example, insist that new manifests adhere to the recommended
form, and that existing manifests be transitioned if they are modified.
If class nesting is ever deprecated in a future version of Puppet, then I
think that will be a signal to prioritize completing the transition
(regardless of whether your manifests actually use nesting).
John
--
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/0050745a-d864-4b2c-b372-b58a66138ce7%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
