Completion server locks in-place built pyd files

[segevfiner]

Environment data

• VS Code version: 1.26.1
• Extension version (available under the Extensions sidebar): 2018.7.1
• OS and version: Windows 10.0.17134.228 x64
• Python version (& distribution if applicable, e.g. Anaconda): CPython 3.7.0 x64
• Type of virtual environment used (N/A | venv | virtualenv | conda | ...): N/A or virtualenv

Actual behavior

The completion server seems to lock pyd files that are built in-place making it impossible to rebuild them without reloading VS Code, since there doesn't seem to be a way to restart it otherwise.

C:\hello_mod>python setup.py build_ext --inplace
running build_ext
copying build\lib.win-amd64-3.7\_hello.cp37-win_amd64.pyd ->
error: could not delete '_hello.cp37-win_amd64.pyd': Access is denied

Expected behavior

It shouldn't lock them like that. It makes it a pain to develop extension modules in VS Code on Windows. At least a command to restart the completion server without reloading the entirety of VS Code can help a bit.

Steps to reproduce:

1. Download: hello_mod.zip
2. Build it in-place: python setup.py build_ext --inplace.
3. Play around with hello.py in VS Code.
4. Try to rebuild it in-place.

Eventually you are likely to hit an "Access is denied". Reloading VS Code will allow to build the module again.

Logs

Nothing relevant under default log level.

[d3r3kk]

Is this while running the new Python Language Server, or while using Jedi?
What is the current setting for python.jediEnabled when you experience this?

[segevfiner]

Is this while running the new Python Language Server, or while using Jedi?
What is the current setting for python.jediEnabled when you experience this?

I didn't change it. It's set to the default for this version: "python.jediEnabled": true.

[brettcannon]

@segevfiner please try setting it to "false" and let us know if the problem persists.

[segevfiner]

@segevfiner please try setting it to "false" and let us know if the problem persists.

The problem doesn't persist as the Microsoft Python Language Server doesn't even try to generate completions for the extension module, instead punting with the message:

Unable to resolve '_hello'. IntelliSense may be missing for this module.

Which is quite annoying since it's a noise warning that is mixed with real warnings from the linter. Does it even support any form of completion for extension modules? (Without any external type info in the style of typeshed).

Even if this doesn't happen with this alternative completion engine, I still think this should be fixed in one way or another with Jedi which is still the default ATM.

[brettcannon]

Yes, extension modules should work so please open an issue about your failure.

And Jedi will not being staying the default. Plus Jedi holding on to the file will probably turn out to be an upstream problem anyway which would mean a short-term fix may not even be possible.