On Tue, Oct 29, 2013 at 12:11 PM, John Bollinger
<[email protected]>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 [email protected].
> 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
[email protected]
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 [email protected].
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.
