On Friday 5 April 2013 at 20:26, henrik lindberg wrote:
> Alright, > on a very similar theme... > > Puppet Saves Christmas > Puppet's Magic Cookbook > Follow that Puppet > Puppet in Wonderland > P is For Puppet > > Back on topic, the way I see the language evolving is that there is one > released set of language compliance levels, and one future, experimental > option to turn on features for usability and field testing before final > decisions are made. > > Starting with the new parser (available with --parser future in 3.2) it is > possible to support multiple language compliance checkers. As we did not want > to be have perfect 3.1 bug compatibility (and drag past sins into the future) > we decided to make the new parser an option in 3.2 as it is more restrictive. > It is reasonable to expect that it is the default parser in Puppet 4.0, and > it will then have a set of language compliance levels, one that is as close > as possible to the latest 3.x version, i.e. with a reltively small set of > breaking changes (from the top of my mind: numbers have to be valid in their > given base, no fat arrow as comma, no assignment to numeric variables). > > The idea is to use the --parser future implementation and ensure that there > is validation that is 3.x compliant and that does mot allow any future > additions (currently there is validation for 3.1 + all additions), an "all > 3.x restrictions" checker needs to be added. > > The idea is to handle the evaluator (i.e. the "compiler") the same way as the > parser (i.e. making it capable of supporting different compliance levels) > since there are many things that can not be checked until > runtime/compilation, and there is behavior that has a certain...uh, odor. > > I hope we can correct the fundamental ones in the Puppet 4.0 evaluator > (there are smells around undef, possibility to alter immutable collections, > around certain comparisons, and a few more corner cases - i.e. things that > are difficult/impossible to support more than one way at the same time). This sounds very good. Might be better having a global change to all these behaviours than a configuration switch for each one of them. > > This work makes it possible for different modules to use different compliance > levels! It is only the fundamentals that must be the same across all > versions. To me this is perhaps the most important goal. Going forward it is > unreasonable to expect that all forge modules must be updated at the same > time in order for a user to adopt a newer version of puppet. How would that work? Should you specify the parser and evaluator to use (or language version) in your Modulefile? Seems hard to me technically to share state between multiple versions of the evaluator. > > Regards, oh... BTW, here is one more Sesame Street Inspired Puppet Movie > Puppet Loves You ! > > - henrik -- Erik Dalén -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
