On Wed, Aug 28, 2013 at 8:04 AM, Henrik Lindberg <
[email protected]> wrote:
> In Puppet 4 the idea is to make "the future parser" the "current parser".
> While it is possible to simply throw the switch, the future parser
> currently transform the parsed result to what the old parser produced -
> this to have identical evaluation (with all its quirks). As seen in
> performance measurements this makes the future parser operate much slower.
>
>
I haven't seen any data yet that points to a particular part of the new
parser that is making it so slow, so I would be careful to draw this
conclusion.
> Thus a new evaluator is required - there is a partial implementation
> available already.
>
>
I agree that we should try to get a new evaluation model in place for
puppet 4, but I'm not convinced that doing that is going to solve the poor
performance that we have seen. I think that we need it simply for code
maintainability reasons.
> When doing this work we have the opportunity to give users new abilities.
> Instead of just having a current implementation of the language and an
> experimental future we can support language revisions.
>
> This means that users can cap the language revision if they want to ensure
> that code does not use newer language constructs (i.e. assert that user
> code is backwards compatible).
>
>
This is definitely possible, but I'm not sure it is desirable. I might be
misunderstanding, but it sounds like you are saying that a module or
manifest author gets to select the language version they want to use. It
now pushes off to readers of puppet code a requirement to understand
various "dialects" within the same codebase.
> Unfortunately, the future parser is not 100% backwards compatible with the
> latest 3.3.x version as it is slightly more strict, and also removes quirks
> in the 3.3.x parser. However, it is capable of validating that code should
> at least theoretically work (and then fail at runtime just like in the
> current 3.x code stream if a 3.x runtime is used).
>
> We currently have the setting "parser" that can be set to "current" (i.e.
> 'latest released') and "future" (i.e. "latest experimental"). We can now
> allow the user to specify a more precise language revision.
>
> Proposal
> ========
> We name the 3.x language revision "R3" which means that it will validate
> all language constructs added in "4" as being in error, and it will do its
> best in informing the user about warnings and errors of the 3.x.
> constructs. Users use this to assert that their code is "backwards
> compatible" in a general sense (even if runtime error may prevent the same
> "R3" compatible source to actually run correctly) - we can probably
> warn/error out on these constructs (e.g. interpolation of function call
> such as "Hello ${get_name_of_world()}").
>
> We then add a "R4" language revision which contains support for all the
> things we add in "Puppet 4" (e.g. iteration/lambdas, heredoc, epp, etc.).
>
> As we continue to add features to the language that are backwards
> compatible we increment the minor number. I.e. "R4" is really "R4.0", and
> we have a progression of "R4.1", "R4.2" etc. We bump the first number when
> we introduce a backwards incompatible language change. For some time puppet
> versions and language revision verions may go in sync-step, but over time
> the language changes will taper off (i.e. will as in "should" or we are not
> doing a very good job).
>
> Now, the user can specify either "current" (the latest, i.e. "R4.0"),
> "future" (which will be "R4.0" as well since we have no experimental
> features in the first release), or "R3".
>
> As a starting point, the language revision could apply to the entire
> runtime, but it is probably of value to allow the runtime to parse and
> validate differently per module. Modules should have the ability to declare
> which language revision they require (and or a cap on the max language
> revision that they work with). The runtime can then treat the modules
> differently based on their requirements. The range definitions already
> available in the module metadata for module dependencies could be used for
> language revision as well.
>
> Ideas needed
> ============
> We need to define how module authors should deal with migration to newer
> language revisions - what if they want to support multiple language
> revisions (perhaps with degradation of features) with one and the same
> module version? We would need to parse with the latest language revision,
> the code would contain conditional logic based on a setting (e.g. "if
> $::setting[parser] > 'R3' { new code } else {old code}" - but how do we
> know which language revision to use in this case? Should it be noted in
> meta data? Older versions do not have "parser" setting, and puppet 3.3 only
> has "current" and "future".
>
> Questions
> =========
> * Do you think it is of value to have a "R3" language revision in Puppet 4?
> * Is it meaningful to have major.minor revisions, or is a single number
> progression enough?
> * Is the ability to allow different version per module overkill? (The
> alternative is to fail if a module is not compliant with the stated runtime
> language revision, or yet another alternative is to just try to use it and
> fail - leaving the language rev dependency to be resolved when adding
> modules.
> * How should we handle "multi version compatible/conditional" modules?
>
>
I know that we've talked about this concept off and on over time, but I'm
not really sure that adding this capability into the system is all that
great (I love it as a thought exercise). It seems like it would add a lot
of maintenance overhead and user confusion.
> Regards
> - henrik
>
>
>
> --
> 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+unsubscribe@**googlegroups.com<puppet-dev%[email protected]>
> .
> To post to this group, send email to [email protected].
> Visit this group at
> http://groups.google.com/**group/puppet-dev<http://groups.google.com/group/puppet-dev>
> .
> For more options, visit
> https://groups.google.com/**groups/opt_out<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 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.
