I'm also a fan of per module which can override a global setting. If it could be part of the metadata.json, that would be ideal and would allow for attestation on the Forge if appropriate.
The global --strict=off should override any module-level setting. Thanks, Trevor On Tue, Feb 23, 2016 at 9:03 PM, Henrik Lindberg < [email protected]> wrote: > On 24/02/16 00:27, Ryan Whitehurst wrote: > >> On Tue, Feb 23, 2016 at 3:22 PM, Walter Heck <[email protected]> >> wrote: >> >>> On Tuesday, February 23, 2016 at 11:31:18 PM UTC+1, Ben Ford wrote: >>> >>>> >>>> Would it be possible in this scheme to mark strict mode per class? I >>>> could >>>> mark my own code as being strict and therefore get compile time failures >>>> when I make a typo myself, but wouldn't have to enforce that on all >>>> third >>>> party code. >>>> >>> >>> >>> Instead of per class I'd like to be able to set it per (module)path. We >>> use >>> r10k and split the role and profile modules to their own modulepath >>> (typically called 'site'), all 3rd party modules live in the standard >>> modulepath. >>> >>> I could also imagine people wanting to set this per environment. >>> >>> Lastly, I think --strict=ignore should be --strict=off, but that's >>> personal >>> preference. >>> >> >> I agree with everything Walter is saying here. Per-class would be >> difficult, but if there was a way to set it per-modulepath, you could >> accomplish what Ben is asking for. It should also definitely be an >> available setting in environment.conf. >> >> > By per modulepath, do you mean per directory containing modules? > the module path consists of multiple directories and the environment has > one. > > Would adding strictness to the module metadata.json work for you? > Then each module author decides how clean their code is. > > --strict=off seems a bit nicer to me as well than does >> --strict=ignore, but I don't care much. >> >> I also bought the --strict='off' since in many cases it also actually > turns of the checking (but not always, and it may just be a > "ignore"/suppression of the logging. > > My first thought is that --strict=warn would make a sensible default >> in this scenario, as it's most similar to puppet's traditional >> behavior of showing deprecation warnings every time. >> >> > In the PR that is up, --strict=warning is the default. > > > -- > > 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/56CD0F8D.1010201%40puppetlabs.com > . > > For more options, visit https://groups.google.com/d/optout. > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 -- This account not approved for unencrypted proprietary information -- -- 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/CANs%2BFoXQSVDKK2M5mXmN8rpAU-xZa0-%3DvOuPCWyYkakwRXtVoA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
