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 < henrik.lindb...@puppetlabs.com> wrote: > On 24/02/16 00:27, Ryan Whitehurst wrote: > >> On Tue, Feb 23, 2016 at 3:22 PM, Walter Heck <walterh...@olindata.com> >> 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 puppet-dev+unsubscr...@googlegroups.com. > 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 puppet-dev+unsubscr...@googlegroups.com. 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.
