On Tue, Oct 29, 2013 at 12:11 PM, John Bollinger
<john.bollin...@stjude.org>wrote:
>
>
> 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.
>
Yes, we know that many manifests rely on this behavior, so it would not be
going away without a deprecation period. At the moment I don't see us
changing the behavior soon, but as John says, conforming to the suggested
layouts is the best way to protect yourself from those kinds of changes.
>
> 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.
>
--
Andrew Parker
a...@puppetlabs.com
Freenode: zaphod42
Twitter: @aparker42
Software Developer
*Join us at PuppetConf 2014, September 23-24 in San Francisco*
--
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/CANhgQXsfqAPbG%2BmWLoAhE-1e-huvDDYJYGLeDVZtUxXxfPp_Cw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
