Repository navigation
Incorrect virtualenv activate script executed | Nushell #22036
Description
Type: Bug
Behaviour
Expected vs. Actual
When opening a new terminal window (Nushell) the incorrect activate script is being executed for my virtualenvironment:
& C:/Users/WayA/AppData/Local/pypoetry/Cache/virtualenvs/cloud-billing-VTFyPfP7-py3.11/Scripts/Activate.ps1
Rather than:
overlay use C:/Users/WayA/AppData/Local/pypoetry/Cache/virtualenvs/cloud-billing-VTFyPfP7-py3.11/Scripts/activate.nu
Steps to reproduce:
- Open a new nushell terminal window
Diagnostic data
- Python version (& distribution if applicable, e.g. Anaconda): 3.11.0
- Type of virtual environment used (e.g. conda, venv, virtualenv, etc.): Poetry
- Value of the
python.languageServersetting: Default
Output for Python in the Output panel (View→Output, change the drop-down the upper-right of the Output panel to Python)
XXX
User Settings
venvPath: "<placeholder>"
venvFolders: "<placeholder>"
languageServer: "Pylance"
linting
• pylamaArgs: "<placeholder>"
• pylintArgs: "<placeholder>"
formatting
• provider: "none"
testing
• pytestEnabled: true
Extension version: 2023.16.0
VS Code version: Code 1.82.2 (abd2f3db4bdb28f9e95536dfa84d8479f1eb312d, 2023-09-14T05:55:25.390Z)
OS version: Windows_NT x64 10.0.19045
Modes:
System Info
| Item | Value |
|---|---|
| CPUs | 11th Gen Intel(R) Core(TM) i5-1145G7 @ 2.60GHz (8 x 2611) |
| GPU Status | 2d_canvas: enabled canvas_oop_rasterization: enabled_on direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled multiple_raster_threads: enabled_on opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok video_decode: enabled video_encode: enabled vulkan: disabled_off webgl: enabled webgl2: enabled webgpu: enabled |
| Load (avg) | undefined |
| Memory (System) | 31.69GB (14.92GB free) |
| Process Argv | |
| Screen Reader | no |
| VM | 0% |
Activity
alex-way commentedon Sep 20, 2023
I will also add that this has been working up until the most recent VSCode update, although it does seem that the extension was also updated yesterday. Will try to find any more relevant changes which may have caused this bug.
alex-way commentedon Sep 20, 2023
Rolling back to
v2023.14.0doesn't fix the issue so I'm going to assume this is some kind've bug in vscode (Perhaps they've changed some kind've API)alex-way commentedon Sep 20, 2023
Found some additional info in the output which is seeming to suggest that my current shell is
commandPrompt:alex-way commentedon Sep 20, 2023
Okay I think I've figured it out.
The following line is looking for the shell being named
nu. https://github.com/microsoft/vscode-python/blob/main/src/client/common/terminal/shellDetectors/baseShellDetector.ts#L33Mine was called Nushell (via the official nushell extension):
Changing to
Nuas the default correctly activates the overlay.However, I will say that I think we should be using both
nuandNushellas the default name in the extension isNushell: https://github.com/nushell/vscode-nushell-lang/blob/main/client/src/extension.ts#L106[-]Incorrect virtualenv activate script executed[/-][+]Incorrect virtualenv activate script executed | Nushell[/+]karrtikr commentedon Oct 26, 2023
Alexander Way (@alex-way) Thanks for the looking into it.
The code you pointed to looks into the path of the shell, not the name. It checks whether that path of shells ends with "nu" or "NU" or any case insensitive comparision.
In case of Nushell, the path of the shell reported to us by
vscode.env.shell(doc link) is Powershell, which seems like a bug on either VS Code or Nushell extension.In case of Nu, the path to shell is actually the path to
nu.exe, so it works out fine.JamzumSum commentedon Oct 31, 2023
vscode-python/src/client/common/terminal/shellDetectors/baseShellDetector.ts
Line 66 in 491c2c8
Kartik Raj (@karrtikr) Could we use a case-insensitive replace?
Since I found my Nushell profile is giving a
C:\Program Files\nu\bin\nu.EXEexecutable path, in which the.EXEextension cannot be removed and theIS_NUSHELLtest does not pass.karrtikr commentedon Oct 31, 2023
Sure, if you send up a PR for it we would be happy to take it.
improve shell identify on case-insensitive system
improve shell identify on case-insensitive system
Improve shell identifier on case-insensitive system (#22391)