Can't connect to jupyter server in vscode - visual-studio-code

My settings file looks like this
{
"python.pythonPath": "/home/username/.conda/envs/myenv/bin/python",
"terminal.integrated.inheritEnv": false
}
And I can see the conda environment in the interpreter that I'd like to activate from vscode interpreter selections but whenever I try to run the a cell in vscode I get a long error message.
Activating Python 3.7.7 64-bit ('myenv': conda) to run Jupyter failed with Error: Command failed: . activate myenv && echo 'e8b39361-0157-4923-80e1-22d70d46dee6' && python /home/username/.vscode/extensions/ms-python.python-2020.8.105369/pythonFiles/pyvsc-run-isolated.py /home/username/.vscode/extensions/ms-python.python-2020.8.105369/pythonFiles/printEnvVariables.py bash: activate: No such file or directory .
I chdecked my $PATH variable and it each directory existed in it. (Looks like how other stack questions suggested it should look as well)
What am I missing? I had it working on a similar machine a couple weeks ago but I can't seem to get it to work now.
I'm on Ubuntu 20.04 if that's important.

I am not completely familiar with the issue, but some digging around lead me to this, try these settings
"terminal.integrated.env.linux": {
"PATH": ""
}
If that doesn't work please reference this link. They seem to be experiencing the same issue as you, but on windows. You may be able to extract more information from it than I could. Sorry if this didn't help.

After messing around quite a bit, I made a new environment and it worked. I'm not sure what I did within that environment to make vscode unhappy with it but vscode didn't like something about it.
Before making the new environment I also ran a few commands including
sudo chown -R $USER:$USER ~/.conda
sudo chown -R $USER:$USER ~/miniconda3
conda update -n base -c defaults conda
I'm not sure what got it to work but I'm happy it's working now!

Related

Visual Studio Code, code command does not start new file

I'm having an issue where if I do code <filename> where the file does not already exist, it does not create a new file.
Normally, vscode would (almost) create a new file, I could write some code, and then save it and it would appear in my file manager. But this just stopped working.
I had a look through all my extensions and uninstalled all the recent extensions. I've reinstalled vscode, still no luck.
I am using windows with wsl, this affects me when running vscode both in windows and in wsl.
Did some googling around, can't find anything useful. Any advice?
I figured out what caused this in case anyone else is having the same problem.
I installed Rust in windows and that seemed to have messed up the code command.
Sorry, can't remember which version it was, I just uninstalled it on windows and noticed that it fixed it.
(p.s: Rust is great, but I have it installed in WSL so don't need it in windows.)
If you are using npm on windows, you can install touch by running npm i -g touch and creating a folder in a specific location by navigating in the location and creating by mkdir <foldername> navigating inside it and using touch <filename>. From there you can simply launch VS Code by running code . in that folder namespace
If you are using WSL (Ubuntu), it comes preinstalled and you can run mkdir <foldername> && touch <filename> && code .
Not exactly what you are looking for but it can work!

"Unable to resolve your shell environment"

On macOS Big Sur, I installed MacPorts and installed bash using it. I set my default shell to the MacPorts version of bash /opt/local/bin/bash by using chsh.
All was well.
I decided I would rather use Homebrew. I uninstalled MacPorts, installed Homebrew, installed bash via homebrew, and set my default shell to /opt/homebrew/bin/bash via chsh.
All was well, except when I am first starting vscode (from Finder) which reports:
Unable to resolve your shell environment: A system error occurred (spawn /opt/local/bin/bash ENOENT)
This is a totally reasonable complaint, since that binary no longer exists. It makes this complaint when launched from Finder, but not when launched from the terminal. There is no reference to this prior version of bash in my user settings.json file, nor is it in my .bashrc.
Where the heck could vscode be getting this path to bash from?!
Edit (2021-10-11): there is something strange going on here. If I open an integrated terminal in vscode:
$ echo $SHELL
/opt/local/bin/bash
$ ls -lh $SHELL
ls: /opt/local/bin/bash: No such file or directory
$ ps -p $$
PID TTY TIME CMD
45388 ttys001 0:00.12 /bin/bash -l
(there are no such problems in the regular macOS Terminal app)
Edit again (2021-10-12):
I tried resetting vscode (via rm -rf ~/Library/Application\ Support/Code).
I tried resetting vscode's cache (via rm -rf ~/Library/Caches/com.microsoft.*),
I downloaded iTerm2 and ran it; it loaded the correct shell (/opt/homebrew/bin/bash) without issue (tried this in hopes of determining if there was some other setting in macOS pointing at the old macports version of bash).
Had the same issue and was able to resolve this by changing the shell for the logged in user (using chsh -s, cf. the hint at the bottom of https://github.com/microsoft/vscode/issues/139867). As this change is not being picked up by VSCode in your currently logged in session, don't forget to explicitly log out and log back in again after performing this step.

Recipe terminated with fatal error: spawn latexmk ENOENT

I have just installed debian 10 as well as vscode. I have been struggling with this for 3 days now.. I installed texlive from terminal with the following command:
sudo apt install texlive
I then installed the latex workshop extension in vscode and tried building a .tex file. The following error popped up:
Recipe terminated with fatal error: spawn latexmk ENOENT.
I then preceded to install latexmk from terminal with:
sudo apt install latexmk
The same error kept popping up after that. The output showed this.
[14:59:34] Recipe step env: {}
[14:59:34] cwd: /home/phoenix/Documents/stellies/year4/2021/s&s-414/pracs/prac-4/report
[14:59:34] LaTeX build process spawned. PID: undefined.
[14:59:35] LaTeX fatal error: spawn latexmk ENOENT, . PID: undefined.
[14:59:35] Does the executable exist? PATH: /app/bin:/usr/bin:/home/phoenix/.var/app/com.visualstudio.code-oss/data/node/bin:/home/phoenix/.var/app/com.visualstudio.code-oss/data/cargo/bin:/home/phoenix/.var/app/com.visualstudio.code-oss/data/python/bin
[14:59:35] The environment variable $SHELL: /bin/sh
I then proceded to review the texlive website. I noticed that i did not set the path variable to include the texlive binaries. The texlive website gives the following path to the binary files : PATH=/usr/local/texlive/2021/bin/x86_64-linux:$PATH
however /usr/local/texlive does not exist on my system for some reason. Where can i find the correct path to the texlive binaries on Debian 10?
I had the same problem. The root cause was: (1) software's bin folder missing from PATH; (2) bad file privileges. Consequently, VSC couldn't access latexmk, which explains the error messages.
In my case, the problem occurred on a mac, and specifically after I installed MacTex, which, in turn, installs Tex Live. I believe the same solution may apply to linux distros too.
Solution:
Claim file ownership (which was originally root) under folder /usr/local/texlive: sudo chown -R <username> /usr/local/texlive, where <username> is the OS-level user name. The fix will work for this specific user. If it is not enough, try instead setting group owner appropriately, and/or consider Step 3.
Add /usr/local/texlive/2021/bin/<software_dialect> to PATH. <software_dialect> depends on the installed software version: in my case it is universal-darwin; on linux it might be x86_64-linux.
If the problem persists, try to change file access permissions under /usr/local/texlive using chmod.
EDIT: As a final step, restart VSC for changes to take effect.
I recently encountered the same problem on MacOS Monterrey (M1 based). I used basictex (just for the context). As required by the installation instruction,
I added TeXLive to PATH,
installed latexmk package to the TeX distribution.
However, still got the same error as OP.
Afte reading the wiki again more carefully, what finally worked for me was as simple as restarting VS Code and MacOS. Everything works as expected after a reboot of the MAC.
I had this same problem on Mac recently, the fix that worked for me was to uninstall and reinstall the LaTeX Workshop extension.
I got the same issue , seems to be a misbehaving from Vscode on MacOS
check if the command is in the path on mac
-which command_you are running example which latexmk
If this output something that means you have your latex installed, otherwise go and installed it and make sure it is accessible via command line.
If latex is installed and you are getting that issue you can just restart your VSCode and everything will be okay.
Had a similar error and came across this post when looking for a solution.
I wanted to use texlive on Vscode with WSL2 on Windows 10. Installing texlive-full in wsl fixed this error for me.
On Mac, this is a way to fix the issue
Step1: reinstall mactex by downloading it from this link: http://www.tug.org/mactex/mactex-download.html
Step2: In your terminal do cd /usr/local, you should see texlive folder
Step3: In your terminal do sudo vim etc/paths to set the environment. Details are in this link: https://www.architectryan.com/2012/10/02/add-to-the-path-on-mac-os-x-mountain-lion/
Step4: In your terminal do /usr/local/texlive/2021/bin/x86_64-linux at the bottom. check the folder to see if the year is correct. Details in: http://www.tug.org/texlive/quickinstall.html.
Step5: Quit VC code completely, and reopen it.

powershell and conda: conda activate env returns command not found

I have pip installed powerline-shell in my base conda env. Switching envs yields the following error:
conda activate <env_name>
-bash: powerline-shell: command not found
I also tried running conda init powershell but it took no actions.
I have miniconda3, with conda 4.7, installed on MacOS Mojave.
I don't know a simple solution to this. I'm thinking you either need to install it in every env (which I don't recommend because it's best to avoid using pip in Conda) or you create a link to the powerline-shell binary in another location that you can keep on PATH to avoid adding the entire miniconda3/bin/ directory to PATH. I've done something like this in the past, but never with a Python entry point before.
I'd try something like
mkdir -p ~/.local/bin
ln -s /your/path/to/miniconda3/bin/powerline-shell ~/.local/bin/powerline-shell
Then add .local/bin to PATH in your .bashrc, probably toward the beginning (e.g., before the Conda section). The path here (~/.local/bin) is totally arbitrary, so adjust to your preferences. Main point is to minimize what you are exposing globally in a shell session.
Note: conda init powershell is for Windows PowerShell users.

nvm, node etc. paths missing from integrated terminal

I am using the insiders edition and zsh with ohmyzsh inside iTerm2 on OSX High Sierra.
If I launch the integrated command line in VSCode echo $path returns:
/Users/username/.yarn/bin:/Users/username/.cargo/bin:/usr/bin:/usr/bin/lldb:
/Users/username/bin:/usr/local/bin:/Users/username/.scripts:
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin
Obviously, the node path, nvm path etc. are missing so the terminal is not much use to me.
But typing echo $path in my terminal outside of VSCode returns:
/Users/username/.nvm/versions/node/v9.0.0/bin /Users/username/.yarn/bin
/Users/username/.cargo/bin /usr/bin /usr/bin/lldb /Users/username/bin
/usr/local/bin /Users/username/.scripts /usr/local/bin /usr/bin /bin /usr/sbin
/sbin /opt/X11/bin
Which has all the paths I need for my development activities.
I have this alias in my ~/.zshrc:
code () { VSCODE_CWD="$PWD" open -n -b "com.microsoft.VSCodeInsiders" --args $* ;}
If I launch code using the alias from an external terminal the node paths are correct.
As far as I can see this is because loading code from the Dock shortcut doesn't load the terminal using my user profile so it loads the profile from /etc/zprofile instead, which sets the path using /usr/libexec/path_helper so it misses all of my important paths that I need for development.
I suspect that most people would prefer the settings from their user profiles to be used. This would mean all of our dev apps would work from the integrated terminal and also the end of the infamous nvm is not compatible with the npm config "prefix" option error caused by the improper setting of paths.
How can I get VSCode to use the environment of the terminal in my user profile when launched from the Dock?
Go to settings and edit integrated terminal
// Object with environment variables that will be added to the VS Code process to be used by the terminal on OS X
"terminal.integrated.env.osx": {},
there you can pass in your variables
The vscode docs also offer a solution for the warning nvm is not compatible with the npm config "prefix" option: currently set to "/usr/local":
https://github.com/Microsoft/vscode-docs/blob/master/docs/editor/integrated-terminal.md#why-is-nvm-complaining-about-a-prefix-option-when-the-integrated-terminal-is-launched
From the docs:
This is mostly a macOS problem and does not happen in external
terminals. The typical reasons for this are the following:
npm was globally installed using another instance of node which is
somewhere in your path (such as /usr/local/bin/npm). In order to get
the development tools on the $PATH, VS Code will launch a bash login
shell on start up. This means that your ~/.bash_profile has already
run and when an Integrated Terminal launches, it will run another
login shell, reordering the $PATH potentially in unexpected ways. To
resolve this issue, you need to track down where the old npm is
installed and remove both it and its out of date node_modules. You can
do this by finding the nvm initialization script and running which npm
before it runs, which should print the path when you launch a new
terminal.
Once you have the path to npm, you can find the old node_modules by
resolving the symlink by running a command something like this:
ls -la /usr/local/bin | grep npm
This will give you the resolved path at the end:
... npm -> ../lib/node_modules/npm/bin/npm-cli.js
From there, removing the files and relaunching VS Code should fix the issue:
rm -R /usr/local/bin/npm /usr/local/lib/node_modules/npm/bin/npm-cli.js