Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should be able to run autopep8 independently of global pycodestyle config #716

Open
Kache opened this issue Nov 18, 2023 · 0 comments
Open

Comments

@Kache
Copy link

Kache commented Nov 18, 2023

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.

Although the README.md says:

The section must be [tool.autopep8], and pyproject.toml takes precedence
over any other configuration files.

It turns out that's not really the case when ~/.config/pycodestyle exists. There are two related sub-issues, in this regard.

internal pycodestyle invocation loads external config

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.

Cannot disable global-config via pyproject.toml

CLI invocation works:

autopep8 --global-config ""

But in pyproject.toml the setting is useless:

[tool.autopep8]
global-config = ""

Because read_config() will load pycodestyle config before read_pyproject_toml() runs, thus config in pyproject.toml does 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

  • Python version: 3.11.4
  • autopep8 version: autopep8 2.0.4 (pycodestyle: 2.11.1)
  • Platform: OSX
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants