On Wed, Feb 24, 2016 at 10:47 PM, Henrik Lindberg < [email protected]> wrote:
> On 23/02/16 01:47, Henrik Lindberg wrote: > >> Hi, I am thinking ahead a bit regarding puppet 5 and how we should deal >> with all the requests for features that require deprecations. (There are >> some related things like requests for additional validation and warnings >> that are different from deprecations). >> >> In the past we merrily started issuing deprecation warnings, but the >> community pretty unanimously said "stop doing that" we cannot deal with >> all of those warnings. Since then we then pretty much stopped doing >> deprecation warnings. >> >> There has also been a long standing wish for a "strict mode" in puppet, >> that like a harsh teacher would point out every itty-bitty problem. >> >> So - what should we do? >> >> In PUP-5889 I have described an idea. This is the text from that ticket >> as it stands right now. >> >> PUP-5889 >> --------------------------------------------------------------------- >> Add a flag --strict to puppet settings. When in effect this will turn on >> --strict_variables, and will also enable other "helpful" but undesirable >> behavior. (Each such behavior to be defined in a separate ticket). >> >> The semantics of this flag should be: >> >> * '--strict=ignore'; no strictness checks are to be performed, nothing >> is reported. >> >> * '--strict=warn'; strictness checks are performed, they are reported as >> warnings, individually configurable warnings follow their own setting >> (i.e. if they are added to disabled_warnings). >> >> * '--strict=errors'; strictness checks are performed, they are reported >> as errors and stop the execution. Further configuration to error >> individually is not supported. >> >> When we add this we promise to not change the set of things that lead to >> warning/error in .z releases, but we reserve the right to do so for .x >> releases. The idea being is that you can safely accept updates for .z >> without having to do anything. For .x releases you may need to step back >> to '--strict=warning' and then correct the problem before going back to >> '--strict=error'. >> >> This scheme should cater to those that are pedantic about following best >> practices and not using deprecated features while those that only care >> at major version boundaries can do so in peace without being bothered >> with lots of deprecation warnings. >> ---------------------------------------------------------------------- >> >> What do you think about this idea? Control all strictness and >> deprecation warnings/errors with one flag, and handle individual ones >> (where applicable) by disabling those checks. >> >> The benefit for us developing puppet is that we can introduce the new >> behavior much sooner and we do not need to add flags for each and every >> kind of validation/deprecation. This means we are more likely to improve >> things as we are not holding off until the very last release in a major >> series (and where inevitably some tickets will not make it). >> >> Ironically, if this feature is liked it will make it into 4.5.0 which >> may be the last in the 4.x series, but no decision has been made yet. >> >> - henrik >> >> > I am following up with a runtime type strictness thing. > > If you have a construct like this in your manifests: > > Notify['left'] -> $stuff -> Notify['right'] > > and at runtime $stuff happens to be an empty array, puppet currently > silently skips the middle part, and thus 'left' and 'right' are not ordered > via the dependency in the middle. > > Should it warn? Is it an error? (I understand there will be a difference > of opinion here if it should always be one or the other, or if it should be > controlled by the --strict option). I just wanted to include it as an > example of something that is not caught by static checking at > parse/validation time. > Oh the chain syntax... I have a couple of reactions: If $stuff is an empty array, it's technically NOT undef, so it has a 'value', but I dunno why you'd put that in a dependency chain. In Puppet, I like that dependencies are expressed for a reason - you went to the effort to express it because it was necessary. So if you did the above and a dependency was not established, my knee-jerk reaction is to consider it at LEAST unexpected behavior which should be warned (if not an error). I'd consider it an error though - you intended a dependency and one was not established. > > Statically we could possibly check if the outcome is statically known > or if there is a potential problem (i.e. where evaluation can lead to > "empty thing in the middle"). But I am not sure what the quality of that > would be and how expensive it would be to implement. > > There are number of such cases where puppet is trying to be helpful and > ends up with a messy situation that it silently ignores or goofs up on. > > - henrik > > > > -- > > Visit my Blog "Puppet on the Edge" > http://puppet-on-the-edge.blogspot.se/ > > -- > 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/56CE8764.2000703%40puppetlabs.com > . > > For more options, visit https://groups.google.com/d/optout. > -- Gary Larizza Professional Services Engineer Puppet Labs http://garylarizza.com -- 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/CAMQzncKfjCwuq5aHsC8Sh7jQtB%2BwBxA9TdDYfbUYjMPLh4kZtQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
