I'm an existing user of pycodestyle and I'm trying to adopt autopep8 in a new project. I want to be able to use autopep8 "cleanly" on its own, independently of pycodestyle config, because otherwise I'd have to manage and consider the interactions between config files of autopep8 and pycodestyle.
autopep8 behavior depends on the behavior of the internal pycodestyle invocation, which will load global pycodestyle config. Thus, config in pyproject.toml does not take full precedence, leading to confusing behavior.
Did some cursory reading, seems like adding the right options to pep8_options can instruct pycodestyle not to read its own configuration and only use what's passed in.
One way out of this is to stop using a ~/.config/pycodestyle, which I use as my "user Python linting settings" outside of any particular project. However, I think these issues should be addressed somehow b/c this is likely a fairly common use case.
I'm an existing user of
pycodestyleand I'm trying to adoptautopep8in a new project. I want to be able to useautopep8"cleanly" on its own, independently ofpycodestyleconfig, because otherwise I'd have to manage and consider the interactions between config files ofautopep8andpycodestyle.Although the
README.mdsays:It turns out that's not really the case when
~/.config/pycodestyleexists. There are two related sub-issues, in this regard.internal
pycodestyleinvocation loads external configautopep8behavior depends on the behavior of the internalpycodestyleinvocation, which will load globalpycodestyleconfig. Thus, config inpyproject.tomldoes not take full precedence, leading to confusing behavior.Did some cursory reading, seems like adding the right options to
pep8_optionscan instructpycodestylenot to read its own configuration and only use what's passed in.Cannot disable
global-configviapyproject.tomlCLI invocation works:
But in
pyproject.tomlthe setting is useless:Because
read_config()will loadpycodestyleconfig beforeread_pyproject_toml()runs, thus config inpyproject.tomldoes not take precedence.Use Case
One way out of this is to stop using a
~/.config/pycodestyle, which I use as my "user Python linting settings" outside of any particular project. However, I think these issues should be addressed somehow b/c this is likely a fairly common use case.Your Environment