Repository navigation
Completion server locks in-place built pyd files #2458
Description
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 deniedExpected 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:
- Download: hello_mod.zip
- Build it in-place:
python setup.py build_ext --inplace. - Play around with
hello.pyin VS Code. - 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.
Activity
d3r3kk commentedon Aug 29, 2018
Is this while running the new Python Language Server, or while using Jedi?
What is the current setting for
python.jediEnabledwhen you experience this?segevfiner commentedon Aug 29, 2018
I didn't change it. It's set to the default for this version:
"python.jediEnabled": true.brettcannon commentedon Aug 29, 2018
Segev Finer (@segevfiner) please try setting it to "false" and let us know if the problem persists.
segevfiner commentedon Aug 30, 2018
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:
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 commentedon Aug 30, 2018
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.
brettcannon commentedon Jul 29, 2019
Closing as this is an upstream issue which we don't have direct control or influence over.