isort does not pickup configuration when it is not in current working directory
#138
Assignees
Labels
triage-needed
Issue is not triaged.
Comments
|
In the meantime, we're going to turn off "source.organizeImports" This was super painful though, and I burned an afternoon tracking this down. |
|
What's interesting though is that when I look in the output, it does theoretically say that its using the same isort executable? |
|
@achen187 When you run using organize imports what is the command that you see in the logs? |
|
And can you set loglevel for isort to |
|
You mean these logs right?
|
|
|
startup logs: |
|
on every save; |
|
The way extension does import sorting on save is equivalent to Can you run |
|
|
@achen187 One thing noticed is that when you ran it from terminal the directory is Temporary work around is to use this argument in the settings Would it be possible to share your project so I can repro this locally and see why there is difference in working directory. |
|
that fixes it! Yeah i suspected the toml file wasn't getting used anymore. Suer, I just gave you read access. Yeah would be good to remove that setting from being required though. Seems like isort should know where to pick up the toml file correctly |
|
This might be a bug in My suspicion is that since we are dealing with plain string. if you run Even this might run into the same issue: I think that the directory location is what is causing this issue. |
|
ah ok, I just cancelled your invite. Hm does the command change only because we're using this arg? "isort.args": ["--settings-path", "${workspaceFolder}/pipeline/pyproject.toml"]" I feel like that argument shouldnt affect whether its plain string or not? |
|
This is the new command in the logs: |
|
When I do the second option, it works: |
|
When I do the first option, it doesn't work, it returns what VScode was doing |
|
The working directory is the problem here.
That tells me this is a bug with |
|
|
Thanks for all the details. I think I have enough info to create a bug on |
|
hm no, I dont think I'm following. I tried both the first and second method from /Users/andychen/dev/nira-data-pipeline The first method did not work, the second did. So that tells me it has to do with the text vs file invocation of isort. It doesn't have to do with the working directory @karthiknadig |
|
It has to do with, |
|
ah got it, so this bug only exists when using plain text method. Ok, sounds good. |
|
Wanted to also chime in here. I have spent the last day tracking down whats going on here. Having issues committing to any of my CI pipelines without manually calling isort. I'm also not seeing "Organize Imports" in the command menu. |
|
@mthanded As identified in the comment #138 (comment) this is an issue with As for the missing "Organize Imports" follow this issue: #139 |
This works for me. But I still see the following error in Output > Log (Remote Extension Host): |
|
@fmunirdev the |
|
Files an issue ion |
karthiknadig
changed the title
isort does not pickup configuration when it is not in current working directory
|
Duplicate of: #53 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi, it seems since updated to VSCode 1.73, the import sort order that gets autosaved has changed.
This is what my import sort used to be:
Now, when I hit save, this is what it changes to:
Here is our settings.json:
pyproject.toml:
When I run
/Users/andychen/dev/nira-data-pipeline/pipeline/.venv/bin/python -m isort ./It goes back to the original sort order I'm expecting.
So it seems like the new Isort mechanism isn't actually using the same command as my manual call?
I then tried to change the setting: "isort.importStrategy": "fromEnvironment"
but then that actually crashed the iSort server.
The text was updated successfully, but these errors were encountered: