isort no longer picks up settings from pyproject.toml when it is not in the workspace root folder

[bluenote10]

Type: Bug

Behaviour

Expected vs. Actual

An important feature when using isort (i.e. organized imports via "editor.codeActionsOnSave": { "source.organizeImports": true }) is that it picks up its configuration for the underlying pyproject.toml.

If that doesn't work, the formatting one gets in the IDE is not in line with what one gets from running isort manually in the command line, which causes discrepancies in the source code.

In previous versions of the plugin / VSCode this seems to have worked fine, but with the update to VSCode 1.7.3 the behavior broke.

It still works if the pyproject.toml is exactly in the VSCode workspace root folder. However, when openen VSCode in a parent folder, isort no longer seems to pick up the pyproject.toml config.

Steps to reproduce:

1. Create a directory structure as

<some-temp-dir>/py_project_root/
<some-temp-dir>/py_project_root/demo.py
<some-temp-dir>/py_project_root/pyproject.toml

with file contents:

<some-temp-dir>/py_project_root/demo.py

from my_package.very.long.subpackage.path import very_very_function_name_causing_linebreak

<some-temp-dir>/py_project_root/pyproject.toml

[tool.black]
line-length = 100
target-version = ['py37']

[tool.isort]
profile = "black"
line_length = 100

2. Make sure the settings.json enables form on save with organize imports:

    "python.formatting.provider": "black",
    "[python]": {
        "editor.formatOnSave": true,
        "editor.codeActionsOnSave": {
            "source.organizeImports": true
        }
    },

3. Open code in <some-temp-dir>, i.e., one level up compared to where the pyproject.toml is.

4. Modify the demo.py slightly and press CTRL + S.

Actual behavior: The editor view briefly "jumps" because isort is applied without the proper config applied. A fraction of a second later black gets applied that fixes the formatting back to what it should be.

Expected behavior: isort should pick up the proper config, which implies running in "black" profile, which avoids the flicker.

Diagnostic data

• Python version (& distribution if applicable, e.g. Anaconda): 3.8.10
• Type of virtual environment used (e.g. conda, venv, virtualenv, etc.): Venv
• Value of the python.languageServer setting: Default

Output for Python in the Output panel (View→Output, change the drop-down the upper-right of the Output panel to Python)

XXX

User Settings

languageServer: "Pylance"

formatting
• provider: "black"

Extension version: 2022.18.2
VS Code version: Code 1.73.1 (6261075646f055b99068d3688932416f2346dd3b, 2022-11-09T04:27:29.066Z)
OS version: Windows_NT x64 10.0.19044
Modes:
Sandboxed: No
Remote OS version: Linux x64 5.4.0-124-generic
Remote OS version: Linux x64 5.4.0-124-generic
Remote OS version: Linux x64 5.4.0-124-generic
Remote OS version: Linux x64 5.4.0-124-generic

System Info

Item	Value
CPUs	Intel(R) Core(TM) i7-10850H CPU @ 2.70GHz (12 x 2712)
GPU Status	2d_canvas: enabled canvas_oop_rasterization: disabled_off direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled multiple_raster_threads: enabled_on opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok skia_renderer: enabled_on video_decode: enabled video_encode: enabled vulkan: disabled_off webgl: enabled webgl2: enabled webgpu: disabled_off
Load (avg)	undefined
Memory (System)	31.59GB (19.02GB free)
Process Argv	--crash-reporter-id f54c5b41-5839-4a51-afc4-de16879a0089
Screen Reader	no
VM	0%

Item	Value
Remote	SSH: bosch
OS	Linux x64 5.4.0-124-generic
CPUs	Intel(R) Xeon(R) CPU E5-1620 v4 @ 3.50GHz (8 x 1197)
Memory (System)	31.26GB (24.91GB free)
VM	0%

Item	Value
Remote	SSH: bosch
OS	Linux x64 5.4.0-124-generic
CPUs	Intel(R) Xeon(R) CPU E5-1620 v4 @ 3.50GHz (8 x 1197)
Memory (System)	31.26GB (24.91GB free)
VM	0%

Item	Value
Remote	SSH: bosch
OS	Linux x64 5.4.0-124-generic
CPUs	Intel(R) Xeon(R) CPU E5-1620 v4 @ 3.50GHz (8 x 1197)
Memory (System)	31.26GB (24.91GB free)
VM	0%

Item	Value
Remote	SSH: bosch
OS	Linux x64 5.4.0-124-generic
CPUs	Intel(R) Xeon(R) CPU E5-1620 v4 @ 3.50GHz (8 x 1197)
Memory (System)	31.26GB (24.91GB free)
VM	0%

A/B Experiments

vsliv368cf:30146710
vsreu685:30147344
python383:30185418
vspor879:30202332
vspor708:30202333
vspor363:30204092
vslsvsres303:30308271
pythonvspyl392:30443607
vserr242cf:30382550
pythontb:30283811
vsjup518:30340749
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
vscoreces:30445986
pythondataviewer:30285071
vscod805cf:30301675
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
cmake_vspar411:30581797
vsaa593cf:30376535
pythonvs932:30410667
cppdebug:30492333
vsclangdf:30486550
c4g48928:30535728
dsvsc012:30540252
azure-dev_surveyone:30548225
pyindex848:30577860
nodejswelcome1:30587005
fc301958:30595537
282f8724:30602487
gswce1:30605430
3d0df643:30604793
dbltrim-noruby:30604474
89544117:30607850

[bluenote10]

Or an even easier way to see that it is not using the config:

<some-temp-dir>/py_project_root/demo.py

import a
import b
import c

<some-temp-dir>/py_project_root/pyproject.toml

[tool.isort]
reverse_sort = true

Now CTRL + S in VSCode re-orders it to a, b, c, whereas running isort . externally re-orders it to c, b, a.

I.e., this issue is particularly problematic if the config content leads to an actually different re-order result from within the IDE vs when formatted externally.

[karthiknadig]

This should be addressed in isort and isort extension. We are moving features contributed via third party libraries to their own extension to make it easier to ship.

[bluenote10]

For the record, this post by @karthiknadig offers more details including a temporary work-around.