-
-
Notifications
You must be signed in to change notification settings - Fork 612
Description
Problem
I am writing quite a complex flake8 plugin with lots of configuration options.
Moreover, I also depend on a lot of other plugins as dependencies. Including flake8-isort.
Here's how my configuration looks like for an end user, contents of setup.cfg:
[isort]
# See https://github.com/timothycrosley/isort#multi-line-output-modes
multi_line_output = 3
include_trailing_comma = true
default_section = FIRSTPARTY
# Is the same as 80 in flake8:
line_length = 79I do not want my users to copy-paste these settings for several reasons:
- They usually make mistakes in this simple action :slight_smile:
- I am losing control over the default configuration: I will not be able to change something in their defaults even if I want to
- It brings a lot of copy-paste. That's totally inconvenient to use and maintain. One new feature or a bug might force you to go trough all your X project and edit the configuration.
Real world use-cases
Several other linters have this feature. Some of them even consider it as a key feature.
- EsLint: https://eslint.org/docs/developer-guide/shareable-configs
- TsLint: https://palantir.github.io/tslint/2016/03/31/sharable-configurations-rules.html
- Stylelint: https://stylelint.io/user-guide/configuration
- Rubocop: https://github.com/rubocop-hq/rubocop/blob/master/manual/configuration.md#inheriting-configuration-from-a-dependency-gem
When working for EsLint for example, one can just create a module with a single javascript file and reuse it everywhere.
I propose the same for flake8.
Each user can create its own set of rules for an organisation / set of projects and reuse it without this amount of copy-paste.
Implementation details
Things to point out:
- It is not a breaking change, everything so work as-is, no major version bump is required
- Without new feature everything should work as-is
- New configuration option should take the lowest priority over existing config options
Configuration priority
Higher takes the priority over lower:
- CLI flags
setup.cfg/.isort.cfg- New option:
--sharable-configuration
Creating new sharable configuration
I guess that reusing entry points here is the best option.
# setup.py
# ...
setup(
name='my-flake8-config'
entry_points={
'isort.configuration': [
'myconfig = some.path:ConfigurationClass',
],
},Then:
- Installing:
pip install my-isort-config - Running:
isort --sharable-configuration=myconfig - Done!
Configuration class API
I am not sure about this. But my vision would be something like:
# some/path.py
class ConfigurationClass(object):
def sharable_configuration(self):
return {
'default_section': 'FIRSTPARTY',
# and any other options for `[isort]` section
}Conclusion
This feature allows to transfer configuration in a reliable and clean way, brings no breaking changes, follows the best practices of other lint tools.
Original issue from wemake-python-styleguide: wemake-services/wemake-python-styleguide#164
The same feature I proposed for flake8: https://gitlab.com/pycqa/flake8/issues/555
I am super excited to help! @timothycrosley what do you think?