On Wed, Feb 24, 2016 at 5:58 AM, Henrik Lindberg <henrik.lindb...@puppetlabs.com> wrote: > On 24/02/16 11:49, Trevor Vaughan wrote: >> >> 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. >> > > > I have been thinking about this for a bit now. Unfortunately it is going to > be very difficult to achieve any sort of "per module" handling of > strictness. While it can be applied statically to parsing, most of the > deprecations are about semantic problems that occur at evaluation time and > in places where there is absolutely no clue about the origin of the logic - > or for that matter a mix of modules and data sources that together resulted > in a state that in the future will be an error.
I'm not even completely sure what the semantics of "per-module" would be in practice anyway. On the forge, like Trevor suggested, any code quality metric that uses this should always be checking everything that --strict checks; you shouldn't be able to say "no, I want to write less-than-ideal or outdated code and have my module appear to have the same code quality as modules that follow latest best practices". In actual deployments (whether testing or production), saying "I only want this information from my custom code, not these forge modules" is useful, but the semantics of a global setting and per-module would be hard. How would I say both "I want deprecation warnings for all my code unless the author disabled strict checking because I'm practical and don't need large swaths of warnings for code I didn't write that just add noise" and "I want to force deprecation warnings everywhere because I'm upgrading major versions and if I don't catch these now it will be a failure when I upgrade"? I think global and per-environment are sufficient. Most of the time, I suspect --strict=warn is going to be all you want anyway. > I think we will start with just a global --strict flag that can be used in > combination with tools like puppet parser validate at authoring time to > catch problems. In production I think you always set --strict=off since you > must already have reviewed and tested the logic that is in production, being > reminded about warnings for all nodes every 30 minutes is not really what > you want. This makes sense. If you had all your code to the point where it generated no --strict warnings/errors, you might use --strict=error to enforce keeping it that way. As well, if you don't have (sufficient) tests for your code (like a lot of internal code), you might use --strict=warn so that those warnings were surfaced somewhere even if you missed certain cases. > It makes a lot of sense to set it per environment. We do have issues with > that though; when you want to treat things differently in development and > production as you must modify a file that is checked in and you must > remember to not check in the settings that are only applicable when an > environment is in test or development state. Still better than just a global > flag. This isn't very different from setting the parser via environment.conf in 3.8, so I think it's fine. Lots of people still don't use some sort of vcs branching workflow,, so this issue wouldn't really affect them anyway. -- 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/CAHTHiAFa%2Bxs3dFeQ88PukS3M-upcqDufiZP3DT3XDo1ZW-paxg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
