-
Notifications
You must be signed in to change notification settings - Fork 292
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Kernel picker doesn't find venv installed ipykernels when setting 'defaultInterpreterPath' #9703
Comments
Thanks for the issue. Can you dump the json for the kernelspecs?
|
|
So the suggested global matches and those kernelspecs don't differ in anything but name. Sounds like a similar issue we had that I thought we had fixed in #8950. Yeah I can't repro myself. I created two identical kernelspecs in a virtual env and they both show up. Can you set this to 'verbose' and post the output log again? It should list all of the kernelspecs we looked through. For example, I ended up with this in the log:
Where these two entries are for the new virtual env I created:
|
It's also strange that your venv entry doesn't show up at all either. What's the root of the workspace? |
The venv does show up (see the one on top, aka Suggested)
|
That might be because it's the notebook's selected environment. What's the root of the workspace? |
I have a double root workspace:
|
The verbose output looks like it's not even looking in the venv where your custom kernels are. This might happen if you opened a folder where the venv wasn't a root folder. That explains the problem then. It won't list venvs that aren't off of the root. Your venv in your example is here:
You'd have to open this folder:
for the venv to be found by the python extension (and for us to get it from the python extension). |
And it does seem to be picked up by extension
|
I'm not sure what that's showing? Did you manually enter the path? I tried creating a subdirectory with a venv and the python extension won't find that virtual environment. Maybe you're forcing it as the active interpreter? Then you'd get the results you see here. There's only one found. |
I'm setting the path on Python extension via |
That's likely the problem then. Python extension doesn't know it's a virtual environment. It's just a python path. Maybe we could try special casing this. For example for a conda env, the python is at the root of the env. Whereas for a venv the python exe is in the Scripts folder (on windows). |
I wonder if generally speaking we should just try to search for kernels under |
Also left #9706 for an alternative where user configures these manually on the workspace file. My use case is probs really niche (we have multi root monorepo and a small script that bootstraps a python environment + ipykernel based on bazel information for the target), but seems a good interface for folks who want to auto generate configuration for large developer bases which are okay having certain defaults set for them (my example, would benefit from having workspace defined kernel since most users will expect it to work the same way their autocomplete does which is specified already on the workspace file) |
also, happy to contribute, but would need some pointers as Im new to VSCode extensions development |
I'd say the Python extension should identify this as an interpreter and list this as active interpreter (when we call their API) which is of type venv when we (jupyter) gets the interpreter information. Else other parts of the extension could fail (e.g. installing packages and the like). Also when setting the PYTHONUSERSITE property. I.e. I don't think we (jupyter) extnsion should special case this (as the root cause seems to be in the Python extension), it should work today in Python extension, as they have the python folder and the executable (via the settings) and with that information it should be easy to determine the fact that its a venv or not. |
Possibly related to #9718 (upstream Python ext issue) |
@DonJayamanne, can you verify that your change above actually fixes this particular bug and then close? Thanks |
can we wait until extension is released before closing? |
We follow the pattern that the VS code team does. Bugs are closed when fixed by a PR. A 'verified' label is added when it's been tested to have been released in our preview bits. |
This has been fixed in the latest pre-release version of the Jupyter extension. |
Applies To
What happened?
Installed kernels under venv don't show up in kernel pick list even after selecting venv as the main python interpreter.
However
src_python_twitter_ml_tfx__tfx
doesn't appear within the list in the kernel picker.VS Code Version
Version: 1.66.2 Commit: dfd34e8260c270da74b5c2d86d61aee4b6d56977 Date: 2022-04-11T07:49:20.994Z Electron: 17.2.0 Chromium: 98.0.4758.109 Node.js: 16.13.0 V8: 9.8.177.11-electron.0 OS: Darwin x64 21.3.0
Jupyter Extension Version
v2022.3.1000901801
Jupyter logs
Coding Language and Runtime Version
Python 3.7
Language Extension Version (if applicable)
No response
Anaconda Version (if applicable)
No response
Running Jupyter locally or remotely?
Local
The text was updated successfully, but these errors were encountered: