Excerpts from Cyril Roelandt's message of 2015-11-03 16:46:25 +0100: > On 11/02/2015 07:32 PM, Davanum Srinivas wrote: > > > > If we can add this command directly in our tox.ini and entirely avoid > > having the bandit.yaml would that be even better? > > Why not, but it'd have some drawbacks as well: > > - should the conf generator be broken for some reason, the gate may end > up being blocked for a while, because fixing it would be harder than > fixing a bandit.yaml file; > - newcomers will feel overwhelmed knowing that a tool writes a config > file for another tool that generates a report, so I'd rather keep it > stupid simple.
We have a hacking plugin for flake8 that we use to apply common rules across projects. Unfortunately, since not all projects are ready to apply those rules at the same time we have to carefully upgrade hacking in a way that doesn't break anyone's gate jobs until their code matches the rules in the new version. That said, since we already have the pattern of a plugin providing a common set of rules, I wonder if we could do something similar for bandit. Maybe the bandit developers don't want a plugin, which would make a wrapper program easier to implement. The wrapper could own the common contents of the YAML file, with each application able to override the settings by updating its local copy of the file. We could then manage updates of this tool in the same way we do for hacking/flake8/pep8. Doug PS - Bonus points for naming the wrapper program "smokey" [1]. [1] https://en.wikipedia.org/wiki/Smokey_and_the_Bandit __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
