Motivation for how yesqa is built

[ikonst]

Naively I suppose a yesqa-like functionality could be built into flake8, similarly to how mypy has warn_unused_ignores and warn_redundant_casts options. This would appear to have a few advantages over current yesqa, e.g. requiring one run over the code, and, when using yesqa as a pre-commit hook, having a single set of additional deps.

I'm curious if there was a specific motivation for building yesqa this way, e.g. flake8 not easy to extend this way, or flake8 maintainers not receptive to such feature, or perhaps yesqa was simply quicker to build this way without touching flake8.

[asottile]

I plan to incorporate the functionality into flake8 but it requires a re-architecture

when I investigated adding the functionality to flake8 in 2017 I wasn't the maintainer and I identified that it would require a re-architecture.

I took over maintenance of flake8 in late 2018 and have been slowly working towards that re-architecture to allow such a feature -- it's currently being tracked in PyCQA/flake8#603