-
Notifications
You must be signed in to change notification settings - Fork 133
Unresolved import for builtin packages after reload #1156
Comments
This happens to our project as well, e.g. for the from __future__ import (absolute_import, division, generators, nested_scopes,
print_function, with_statement)
import os
import re
import subprocess
import sys I am using the language server (i.e this is our setting As it is quite a basic functionality to be able to get IntelliSense for builtin packages it hampers development speed by quite a bit. |
Same problem with python 3.6. I do not really think that this problem is related to python version though I did not test all versions. I noticed this problem after using
Before the problem occurs all autocomplete functions works well. After the problem sys, time and other builtin packages are unrecognized. Edit: Edit2:
using runInTerminal and macros which seem to work fine and sys does not throw unresolved import . Also language server was not reloaded which seem to be related. In trace log from language server first run analyses shows |
Interesting. The reloading is due to our file watcher detecting changes on disk to reload files (for package installation and so on, see also #1076 for the issue on improving that mechanism). It might be the case that when we go reload modules, some builtins are getting lost. |
@johnybx Also, we'd appreciate it if you could try the daily build, which includes a few race fixes among other things that we think could have fixed the missing builtins issues: "python.analysis.downloadChannel": "daily" |
@jakebailey I already tried
but it did not resolve this issue. |
I have the same issue with builtin 'sys' and 'time', and I tried the daily build. It did not help. Python version is 3.7.3. So it's not limited to 2.7. |
I'm occasionally hitting this problem. I'm currently running 1.36.0-insider. I'm developing against a folder opened inside a container.
|
Now that I've fixed the path watcher to watch the correct things, I've observed this happening for some libraries, in my case |
@jakebailey Problem still occurs - builtin packages are unresolved after reload of language server. |
@AlexanderSher @jakebailey still occurs in Microsoft Python Language Server version 0.3.47.0. |
Changes are not in stable feed yet. "python.analysis.downloadChannel": "daily" is 0.3.59. We do not push builds with large changes into stable immediately, so when an issue is closed, it does not mean the fix shows up in stable next day. |
That is certainly a good point to make but, as someone who does use the stable build, I get frustrated by the following:
|
It is hard to say which version will include particular change since version is assigned by build and does not directly relate to PR or a date. 0.3.59 is published to stable. "may" fix reflects the fact that we found that earlier PR was not complete and needed additional changes that affect the imports area, but since we do not have stable repro internally, we have to wait and see if changes applied indeed fix the case. Agree, #1156 should stay open until verified. |
Is it possible to do more with the Releases feature in GitHub in that respect? Presumably a build takes a specific point in time in the git history and therefore that could be tagged with the version assigned by the build? I realise I'm going off the point of this issue now so I'll leave it there. I'm just trying to see if there is any way for consumers of the Python Language Server to get a better insight into what each version has fixed or had added so that we know when to try and test issues like this one. Thanks. |
@AlexanderSher @jakebailey @MikhailArkhipov issue still occurs in |
At the moment, the version numbers aren't "true" semver; the last number is actually just a build number we trigger manually (versions may skip or repeat commits). Improving this is something that'd be good once we're more stable. |
We believe this to be fixed. We'd appreciate if anyone with this issue could try out the beta and see if the issue goes away. "python.analysis.downloadChannel": "beta" |
@jakebailey i am experiencing this with RemoteSSH connection. The above line doesn't appear to work (the line in the config is dimmed, as if the option does not exist), so i can't test with the beta/daily version. I am using VSCode Insiders build. How do i get the latest Python extension? |
The option is not documented, which is why VS Code does not think it exists. If you set beta and reload, the extension should download an updated copy. Beta is currently 0.3.72. The language server and the extension are versioned separately; you don't need to get the latest extension in order to get the latest language server. |
@jakebailey i believe the issue is fixed for me, thanks! at least i haven't seen any problems so far. |
this fixed it for me so far |
The fix is now out in stable, so you don't need to set this variable to get this fix (though we always like testers). |
@AlexanderSher I'm still seeing this issue with 'itertools' import under centos, is it a known problem? |
Unless this occurs only after a reload (package install), then it's likely not related to this old issue. I'd appreciate it if you could file a new issue with your info. |
- Fix the order of builtins initialization during reload (may fix microsoft#1156) - Remove some of the dead code - Add file size information to the module import
…ad (microsoft#1496) * Fix microsoft#1156: Unresolved import for builtin packages after reload * Address CR comments
@schlamar commented on Mon Jun 03 2019
Environment data
Expected behaviour
No errors for builtin packages.
Actual behaviour
Import of builtin packages like
time
,itertools
andoperator
are sometimes marked as unresolved import.Steps to reproduce:
Don't know, this happens randomly.
Logs
(Right now, I don't have a Console Log in case of this error. I will submit them as soon as this happens again.)
The text was updated successfully, but these errors were encountered: