Difficult/unintuitive to modify individual VS Code & ext. settings: WSL+Anaconda issue - conda: command not found

[magnucb]

Issue Type: Feature Request

I try to use the WSL terminal integrated into VS Code.
I'm filing this as a feature request, whereas I intend it as constructive criticism towards some specific elements of the UI (graphical and otherwise), and I would possibly hope for some helpful pointers in return.

Problem as in action, until today:
Until today, every time I open new terminal, some process will be trying to launch a script from a preconfigured path to Anaconda in ..\ProgramData\et cetera, into the current WSL.

WSL would then interpret this command and fail, considering that the preconfigured path was full of backslashes, which it would read as escape characters; certainly not interpreting it as the intended command: "activate conda".

This error message's behaviour persisted even when I tried to choose either of my python interpreters:

• "Python 2.7.15 64-bit ('base': conda) - C:\ProgramData\Anaconda2\python.exe", or
• "Python 2.7.15 64-bit ('Anaconda2': conda) - ~\Anaconda2\python.exe"

I've had to spend good hours for days now, towards figuring out even why this is/which settings does this/where can I modify them.

Reflections, as in: "Letting you understand the circumstances of my problems, and bullet pointing my suggestions for you" (it may be a wall of text for you, but it might also be valuable for you to know how your interface is perceived from even a single user's experience)

I am a newcomer to VS Code, having been using Sublime Text for years (simply decided to try out VS Code because it was bundled with Anaconda, and I'm very pleased overall). However, to me the problem here is not a lack of implementation on VS Code's part, but to provide a relatively intuitive way of leading the user towards the correct settings involved in this. As requested in Globally WSL support , there should be an over-arching portion of the settings concerning how the integrated terminal and the extensions are directed to a specific command terminal, be it bash or cmd.

• I've already upvoted the afore-linked issue, because this seems to be a feature that should be taken for granted to be included, when the rest of VS Code appears to so well-made and polished (and I think it is, so please take this as a compliment). While his and my own problem are not exactly the same, I believe our problems are connected in how VS Code is currently designed/developed.

I'm also perplexed to the contrast of how well-documented every single feature of VS Code is - except for how to manually edit individual settings for individual extensions (for, after all, my issue could stem from one of my extensions!). I've also google this, but I suspect that the last few years of sifting through StackExchange- and Numpy sites, by way of google, is polluting the results somewhat: only to say that I've never had these specific problems before. In any case: surely, these extensions have their own settings that should be configurable, but I've looked through UI elements of VS Code that would otherwise be logical places to find these configurables, or even through the settings.json that I could find: and I couldn't find any settings towards modifying extensions, nor anything that lead toward an Anaconda-launchable script's path related to ProgramData.

So, as far as I can tell, it seems that the user is intended to add their extension-specific settings' modifications into settings.json (as modifyable by the user). Am I correct?

edit1: It seems that this is how the user is meant to specify extension-related settings - no extra files for extension-specific settings. Nice! Embarrassingly - upon a VS Code restart and closer inspection - I see that searching for specific extensions in the normal settings.json would display these settings vividly.

I might simply have not noticed that the settings-results that were displayed as I was searching earlier, were in fact related to extensions that I had installed (and maybe my VS Code at some point simply needed to restart in order to work properly, although it didn't tell me to reload).

As such, because I've spent a good deal of time probably looking at extension-specific settings while looking for them; having them staring at me right back into my face, while I myself believed that I was looking at VS Code's default jungle of settings:

• It might be a good idea to simply label extension-specific settings in the settings.json (color code, for instance), so that it is immediately clear to a user trying to skim through settings, which options are indeed extension-specific.

In case I am, how about the same solution as how one would edit the settings.json, i.e.:

• I think that you should be able to open the extensions' bar, right-click an extension, and that there should be an option to "open extension's settings". Selecting/clicking this option should then open a double-column layout of the specific extension's modifyable settings on the left column (un-editable, as always); and on the right column there would be the settings.json file that is intended for the user.

edit1: In other words, simply a hyperlink of the default behaviour from looking through the settings the normal way.

I did find launch.json by accident in the settings-GUI, and could not remember how to get back to it, until I today found it in the drop-down menu from "Debug", called "Add configuration" - not at all my first thought, when I'm "merely" looking for how the 'integrated terminal' works. So then, finally, I thought; that these were settings that might have something to do with the that issue I began with, but it became clear to me that the file didn't mention Anaconda, nor did it refer to a pre-configured path related to the Windows-folder ProgramData: so again, a dead end.

My reason for not-yet-disabling my extensions, was that when I even booted up VS Code for the very first time, it was to open a python script, and several things immediately installed by their own - and I was also fairly quick to configure VS Code to utilize WSL, too: And with these circumstances, along with that I've always seen that Anaconda-related error message when opening the terminal, led me to believe that the problem was fairly ingrained in VS Code's interpretation of WSL, and not to do with the extensions in themselves - maybe even in the fact that installing VS Code from Anaconda ingrained Anaconda itself into VS Code; and I don't consider Anaconda itself to be an extension to VS Code.

As it turns out, I believe there was some truth to my hunch: the error message finally stopped when I created a ~/.bash_profile-file in WSL (...didn't need one until now!), wherein I sourced the my WSL's ~/.bashrc file - into which I also added the line source ~/Anaconda2/etc/profile.d/conda.sh. Seeing as I mostly install Anaconda from convention, merely for acquisition of the collection of python packages found within, this was not my first thought, and thus I give cudos to source activate is broken in 4.4 for zsh .

At this point I went back to VS Code settings, and made sure that both the pythonPath and the condaPath refer to their installations within the WSL environment: "python.pythonPath": "~/Anaconda2/bin/python" and "python.condaPath": "~/Anaconda2/bin/conda", respectively. Opening the terminal now only shows me what I've myself set the ~/.bashrc to display upon startup; no error messages.

I still have no idea if there's some part of Anaconda that has ingrained itself into VS Code, and is actively trying to be able to activate in the background without my knowing, because that is exactly how it seems like they are doing:
That the error message which I had from the beginning, was simply Anaconda from the Windows side (and not inside WSL) that has somehow configured VS Code into checking any terminal environment that opens, if there is Anaconda inside - not even running Anaconda, just checking if Anaconda is potentially there to be run.

And I say "seems", because I still cannot find any settings, modified or not, that tells any integrated terminal to do this. At least now, if it's still doing it, then thankfully it's keeping it to itself.

"Snakes! - Why did it have to be snakes?!"

VS Code version: Code 1.28.2 (7f3ce96, 2018-10-17T00:23:51.859Z)
OS version: Windows_NT x64 10.0.17134

[Tyriar]

Thanks for the feedback. We're looking at improving the overall WSL experience in #63155, your problem seems largely a problem with the Anaconda build though so you might have more luck going over the flow with them.