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 > <[email protected]<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 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. 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 post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-dev. For more options, visit https://groups.google.com/groups/opt_out.
