Bandit 的重构配置¶
问题描述¶
随着更多测试插件和选项被添加到项目中，Bandit 的配置文件变得越来越复杂和庞大。 采用者反映，在每个项目的仓库中维护 Bandit 配置文件是一件令人不快的苦差事。
提议的变更¶
本提案旨在重构 Bandit 的配置系统，目标是消除在不需要对预设默认值进行重大偏差的情况下，包含任何项目特定的配置文件。 为了实现这个目标，我们首先研究了现有的配置系统。 该配置文件分为三个主要区域，我们将分别处理这些区域。 这些区域是
可调整的选项，用于调整 Bandit 运行时中的各种细节
插件选项，用于控制单个测试插件的操作
配置方案，用于选择要运行或不运行的测试插件集合
可调整的选项¶
Bandit 的配置中提供了许多可调整的选项。 最初的设想是，这些选项在配置 Bandit 的运行时行为方面很有用。 然而，在所有实际场景中，这些选项都是多余的，并且保持默认设置。
我们提出的策略是删除这些不必要的配置选项，并依赖 Bandit 作者提供的合理值。
插件选项¶
本节代表了配置数据中最大的部分，因此也是采用者面临的最大痛点。 它包含所有可用测试插件的大量配置选项，如果没有这些选项，许多插件将无法正常工作或根本无法运行。 许多插件的可用性也直接取决于此部分配置中提供的数据（例如，黑名单插件），因此此数据应被视为插件功能的一部分。
我们提出的策略是修改插件系统，以便为所有可配置的测试插件提供合理的默认值，直接在插件代码中。 只有在需要时，才能通过外部配置覆盖这些数据。 这消除了在默认功能足够的情况下对任何配置数据的需求，而这种情况应该占大多数。
为了实现这一点，测试插件系统将被修改为使用类来代替当前使用的函数，为每个插件提供类。 每个类将提供一个或多个测试方法，等效于当前的测试函数，以及一个方法来返回由该类提供的所有测试方法共享的默认配置。 在默认情况下，此配置数据将发送回每个测试方法，或者如果存在外部配置，则可以被外部配置覆盖。
除了消除对配置文件的需求之外，这种方法还有两个优点。 首先，它允许来自第三方的外部插件提供配置数据以及他们的插件，而无需编辑 Bandit 项目发货的中央默认配置文件。 其次，它允许配置生成工具自动发现所有可用插件，并通过简单地调用每个发现的插件类的配置方法或其中一些期望的子集来创建默认配置文件。
配置方案¶
本节是 gate 采用者的主要关注点，他们可以在这里选择要在其项目上运行的插件测试集合。 它几乎总是作为初始 Bandit 设置的一部分进行配置。
我们提出的策略是提供一些新的机制来指示要运行的测试集合，从而弃用当前的情况。 首先，我们允许将配置方案配置在各自的单独文件中，这些文件使用比当前单个配置文件简单的布局。 其次，我们将允许直接从 Bandit 的命令行界面指定测试集。
第一个选项将允许 Bandit 的手动用户轻松创建和重用他们可能需要经常使用的各种测试方案。
第二个选项将允许 gate 采用者将他们期望的测试集作为 tox.ini 文件中给定的 Bandit 命令调用的一部分列出。 这具有先例，并且与当前配置 PEP8 测试的方式密切匹配。
为了进一步改进当前状况，再次借鉴 hacking/flake8/pep8，Bandit 将支持测试插件的规范编号系统。 这些数字名称可以在任何可以使用通常的描述性但通常笨拙的完整测试名称的地方使用。
一个示例规范方案可能如下所示
B1xx - 黑名单函数 B2xx - 黑名单导入 B3xx - 注入…
关于黑名单的说明¶
如上给出的示例方案所示，每个黑名单模块和导入现在也将分配一个唯一的标识符。 这里的意图是帮助配置这些冗长的黑名单。 因此，虽然黑名单模块和方法将共享通用逻辑，但单个项目将可以区分，就像在配置 Bandit 时它们是单独的测试一样。
实现¶
请参阅提出的更改，将对 Bandit 进行指示的更改以实施新的配置方法。 将保留对旧配置文件的支持，但其使用将被标记为已弃用，并且当使用文本格式化输出和旧式配置时，将向用户呈现指示此消息的消息。
负责人¶
Bandit 核心团队将领导这些更改的开发。
- 主要负责人
tkelsey tmcpeak
里程碑¶
- 完成目标里程碑
Mitaka 3
工作项¶
从 Bandit 配置中删除各种选项
添加一个单独的文本格式化程序，其中包括终端输出颜色，从而消除了对这些颜色进行配置的需要。
添加对外部配置文件支持。
将插件转换为实现一个或多个测试并提供配置生成函数的类。
为每个插件（包括黑名单模块和导入）分配规范编号。
添加对通过 CLI 进行测试选择的支持。
更新配置生成器以输出默认配置。
删除与 Bandit 捆绑的配置文件。
依赖项¶
N/A
