SQLFluff is extensible through “plugins”. We use the pluggy library to make linting Rules pluggable, which enable users to implement rules that are just too “organization specific” to be shared, or too platform specific to be included in the core library.
Creating a plugin¶
We have an example plugin in sqlfluff/plugins/sqlfluff-plugin-example which you can use as a template.
Few things to note about plugins:¶
Right now, only Rules can be added through plugins. Each plugin can implement multiple Rules.
The name of a plugin should start with “sqlfluff-plugin” to be valid.
A plugin may need to include a default configuration if its rules are configurable: use plugin default configurations only for that reason! We advise against overwriting core configurations by using a default plugin configuration, as there is no mechanism in place to enforce precendence between the core library configs and plugin configs, and multiple plugins could clash.
A plugin Rule class name should have the structure: “Rule_PluginName_L000”. The ‘L’ can be any letter and is meant to categorize rules; you could use the letter ‘S’ to denote rules that enforce security checks for example.
A plugin Rule code includes the PluginName, so a rule “Rule_L000” in core will have code “L000”, while “Rule_PluginName_L000” will have code “PluginName_L000”. Codes are used to display errors, they are also used as configuration keys.
We make it easy for plugin developers to test their rules by exposing a testing library in sqlfluff.testing.
Would you like to have other parts of SQLFluff be “pluggable”? Tell us about it in a GitHub issue 😄.