Sorting of imports (isort) is different if the file has unsaved modifications

[PeterJCLaw]

Environment data

• VS Code version: 1.32.3 (have also seen this on older versions)
• Extension version: 2019.2.5558 (have also seen this on older versions)
• OS and version: Ubuntu 16.04.6
• Python version: 3.5.2 (have also seen this on other versions)
• Type of virtual environment used: venv
• Relevant/affected Python packages and their versions: I currently have isort 4.3.15, though I've seen this on older versions

Expected behaviour

That when running the "Sort Imports" command on a file, the imports are sorted according to my setup.cfg config regardless of whether the file is currently saved or not.

Actual behaviour

When running the "Sort Imports" command on a file:

• If the file is saved, my setup.cfg config is respected
• If the file has modifications, my setup.cfg config is not respected

Steps to reproduce:

Given this config:

# setup.cfg
[isort]
length_sort = True

# demo.py
import os
import logging
import collections

1. put setup.cfg and demo.py next to each other in a new folder
2. open that folder as a workspace in VSCode
3. open demo.py
4. "Sort imports" within demo.py, it should be unchanged
5. edit demo.py, without saving it
6. "Sort imports" within demo.py, note that its imports have changed ordering to ignore the length_sort option

This reproduces with much more complex configs, and other options are also ignored, so I strongly suspect the setup.cfg file isn't being picked up as a whole if the file is modified.

[PeterJCLaw]

I'd be up for trying to fix this if that would help. Do you have any suggestions around how to approach this?

From what I can see the issue here is that we're asking isort to operate on a temporary file like /tmp/tmp-19006aGV59gsvAPHQ.py rather than on a file within the project workspace.

Would a suitable fix be to put the temporary file within the project workspace instead of within /tmp?

[DonJayamanne]

Dup of #2980

[PeterJCLaw]

I don't believe that this is a duplicate of #2980 -- that issue seems to be about new, unsaved files (which presumably don't have a well-defined project nor path on disc). In contrast this issue is about unsaved modifications to existing files. I've updated the title to clarify that.

[PeterJCLaw]

Interestingly it looks like isort now supports being passed the content of the target file on stdin. While this project has a comment about this not being broken, I'm guessing that that pre-dates it being fixed (PyCQA/isort#384).

In any case, having tested the behaviour using stdin seems to correctly find configuration from the current directory (or ancestors), so I think this is a better solution than moving the temporary file. This would likely also solve #2980 for isort.

[PeterJCLaw]

My current plan for this is to extend the IProcessService such that it supports passing something usable as the stdin of the underlying process.

I tried doing this using the existing SpawnOptions.stdio and passing essentially [myReadableWithFileCotent, undefined, undefined], but that didn't seem to work. I got errors that the Readable I was passing wasn't suitable; I'm guessing because it didn't have an actual file descriptor. If I'm missing something about this error I think this approach would be the best though.

I'm currently working on passing through a (new) IBufferEncoder to the ProcessService everywhere, with the idea that we can either add an input?: string attribute to the SpawnOptions or to the actual exec function signature. Input on whether it would be preferable to have the input specified in the function signature directly or as part of the options would be welcome.