isort not honoring setup.cfg

Environment data

• VS Code version: 1.34.0
• Extension version (available under the Extensions sidebar): 2019.5.17059 (28 May 2019)
• OS and version: macOS 10.14.4
• Python version: 3.6.7 (miniconda)

Issue

I added

  "editor.codeActionsOnSave": { "source.organizeImports": true }

to my user settings to sort imports with isort. I’m also using black as a code formatter. On multiline imports these two tools format imports very differently, leading to alternating formatting and jumping code from one save to the next as shown in this gif.

I was able to prevent this by configuring isort to use black’s formatting by adding

[isort]
multi_line_output = 3
include_trailing_comma = True

to my setup.cfg as indicated in the comments of this black commit.

Now, the file is stable if I repeatedly save it without changes in between. But if I modify the file and then save, the imports briefly flash to isort formatting before reverting to black formatting. So unlike before, the final result is now always black formatting but there’s jumping code every time I modify and save.

This seems to suggest that isort is still being run by VS Code with its default settings when the formatOnSave callbacks are triggered. Is there any way to respect the setup.cfg settings in the isort callback?

Additional Info

Related Issue: #2301

[markedwards]

Any update on a fix for this? Its still happening in 1.44.2 and this issue has been open for nearly a year.

[mikeroll]

The real cause of this is that the bundled isort (sortImports.py) gets invoked without any directory context. At best, the cwd of isort is /, while it really should be ${workspaceFolder} – obviously there’s no relevant setup.cfg under /. This also explains why "python.sortImports.args": ["--settings-path=...] fixes things.

Formatter invocations do set cwd properly, so I guess the solution would be to copy their cwd behaviour (maybe extract common parts even?). I hope to get around trying that soon.

@DonJayamanne I get the reasoning behind the autopep8/yapf tmpfile hack, however, isort has worked perfectly as < file.py | isort --diff - for quite a long time. Why the tmpfile dance for isort then, is it still relevant?

On a related note - is there a reason you guys bundle your own isort with the extension? Why not go the way of formatters and have it under the user’s control?