Replies: 1 comment
-
While I'm not sure of the exact reasoning, I think in general since we only support both a subset of the original functionality and new functionality it's hard for us to use the previous configuration and provide reasonable validation of the configuration a user provides. There's a tool for this purpose https://github.com/astral-sh/ruff/tree/main/crates/flake8_to_ruff#flake8-to-ruff
What do you mean by this? |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
We are currently working on porting our company over from isort and flake8 to ruff. One of the difficulties here is that ruff doesnt ingest existing configuration, which means porting over all the flake8 and ruff config from setup.cfg into pyproject.toml. Easy enough to switch, and our CI pipeline can now take advantage of ruff. The bigger issue is that everyones IDE needs to support the ruff config format, usually via more custom ruff plugins, while a lot of flake8 plugins have existed for many years. What was the reason for forking the config, instead of ruff just parsing existing tool config and erroring on unsupported config?
Beta Was this translation helpful? Give feedback.
All reactions