Develop Reference

Make VS Code terminal match debug environment on a Mac

I'm teaching a beginners python class, the environment is Anaconda, VS Code and git (plus a few extras from a requirements.txt).
For the windows students this runs perfectly, however the mac students have an existing python (2.7) to contend with.
The windows students (i.e. they have a windows computer), their environment when they debug matches their console environment. However the mac students seem to be locked to their 2.7 environment.
I've tried aliasing, as suggested here and here
alias python2='python'
alias python='python3'
alias pip2='pip'
alias pip='pip3'
I've modified the .bash_profile file
echo 'export PATH="/Users/$USER/anaconda3/bin:$PATH"' >>.bash_profile
Both of these seem to work perfectly to modify their Terminal environments, when launched externally to VS Code. Neither seem to do anything to the environment launched from [cmd]+[`].
I've also tried conda activate base in the terminal, which seems to have no effect on a python --version or a which python
They can run things using python 3, but that means that they need to remember that they are different to the other 2/3 of the students. It's othering for them, and more work for me!
The students are doing fine, launching things from their external terminal, but it would streamline things greatly if the environments could be as consistent as possible across the OSs.
Whilst they are complete beginners, they can run a shell script. They currently have one that installs pip requirements and vs code extensions.
Is there a configuration that will keep the terminal in line with the debug env?

In my opinion the best practice is to create Python virtual environments (personally I love using conda environments, especially on Mac where you stuck with unremovable old Python version). Then VSCode will automatically (after installing very powerful Python extension) find all your virtual environments. This way you will teach your students a good practice of handling Python zoo a.k.a. package incompatibilities. Terminal environments settings will be consistent with VSCode, without being dependent on unneeded any more aliases. Obviously, virtual environments are OS independent, so you will be more consistent and remove unnecessary confusion between different students.
The additional bonus of the virtenvs is that you can create one exactly according to your requirements.txt and switch from one to another with a single click (in terminal it takes two commands: deactivate -> activate).
You can read more about how to handle Python virtual environments on VSCode site

Given the aliases are run just once and are not persistent in .bash_profile, python targets the default interpreter rather than the expected conda python3 interpreter.
Try to symlink conda's python3 executable to capture the python namespace
ln -sf /Users/$USER/anaconda3/bin/python3 /Users/$USER/anaconda3/bin/python
This will create or update the symlink. Use the same approach for pip and pip3.

Python in vscode let's you select which interpreter will be used to run the scripts.
It is in settings under "python.pythonPath", just set it to point to the interpreter of choice.
It can be set on a project basis as well (which is how you ensure that a project that has a virtual environment will execute using that interpreter and packages), you just select Workspace in the settings pane and add the desired python interpreter there.

Emacs and conda workaround

I'm using emacs and anaconda.
I have this in my init.el:
(setenv "WORKON_HOME" "/home/user/anaconda3/envs/")
And conda on my path:
# added by Anaconda3 installer
export PATH="/home/user/anaconda3/bin:$PATH"
but emacs can't find my conda environments, which I understand it is supposed to be able to do..
So, when I run C-c C-p to start a new session, and C-c C-c, it fails to import my packages which are installed in a conda environment, with ModuleNotFoundError.
Since I have added this to my path and it still doesn't work, I am trying to work around this, and still be able to run my conda applications from emacs.
I can open a shell in emacs with M-x shell, then source activate myenv, and run python.
I now want C-c C-c to copy into /this/ shell. How do I mark this shell buffer as a python process to send my file.py's text to on C-c C-c, rather than just a shell shell?
Update1
I've also looked at the following references:
https://emacs.stackexchange.com/questions/20092/using-conda-environments-in-emacs
How does conda-env list / conda info --envs find environments?
But neither package works for me. I still get, when I try:
conda-env-list
*Conda envs*
Produces a blank buffer.
And this for pyvenv-workon:
pyvenv-workon
Work on: (empty)
These environments very much exist, and it makes it impossible to use emacs as a python IDE if I can't run my code.

What I found works for me is to use the conda package from ELPA and set two of its configuration variables to point to my Conda directory. The following snippet does the trick in my .emacs:
(use-package conda
:ensure t
:init
(setq conda-anaconda-home (expand-file-name "~/miniconda3"))
(setq conda-env-home-directory (expand-file-name "~/miniconda3")))
conda-anaconda-home is the equivalent to the ANACONDA_HOME environment variable (i.e. contains all files of your Anaconda installation)
conda-env-home-directory - is the directory where your virtual environments get stored (within the envs subdirectory)
With this configuration I'm able to run M-x conda-env-activate and have access to all previously created envs.

Programs inherit the environment variables from the shell that spawned them. The way conda and virtualenv work is by overriding the shell's PATH variable. They do this so that the OS finds the new version of the app (conda's or virtualenv's) instead of the default one installed with the OS (Macs come with an ancient version of python).
So, what is happening here? If you start Emacs by double clicking on the OS icon it will inherit the default shell environment variables. So when you try to call a library that you installed with conda (or equivalently with virtualenv and pip), because you are using the default OS path, the OS is finding the default version of python (and crucially the default version's libraries). The default version of python is going to respond "I have no idea what library that is."
How to fix? One reliable way is to not start Emacs by double clicking on the OS Icon. Here is what I do most days:
1) start a console/terminal
2) switch to the conda environment `activate py37`
(or with virtualenv: `source .py37dev/bin/activate`)
3) start Emacs from that same shell that has the modified environment variables.
On a Mac its: `/Applications/Emacs.app/Contents/MacOS/Emacs`
(I use a installed version of Emacs on the Mac because the one that
comes with Mac is ancient).
On Linux and Windows the path to EMacs will be different but the idea is the same.
4) start a shell inside Emacs and you should see the shell looks the way it does
in your conda shell (or virtualenv shell)
here it what it looks like for me:
see how the version of python is not the default OS python? Its the one from the virtualenv + pip environment (conda works the exact same way, just the start envirmonment is a different command)

I tested the solutions given in the answers of Wojciech Gac, of Mittenchops and James Anderson.
While solution of James Anderson's solution is by far the easiest, it comes with a few problems:
First, you have to reactivate the environment in each shell process you spawn in emacs. There is also the possibility that emacs has a different pythonpath, therefor reluctantly using system python and not venv python.
The solution with conda.el is somehow weird. In Melpa it is listed as obsolete and with instructions of https://github.com/necaris/conda.el it won't recognize the environments on my certain machine.
On the same machine the solution with pyenv as mentioned in https://emacs.stackexchange.com/a/20093/28567 is working like a charm.
Therefor you only need to install with M-x package-install search for pyenv and then insert following two lines into .emacs:
(setenv "WORKON_HOME" "~/anaconda3/envs") ; /anaconda3 || /miniconda || wathever path your conda installation is located at
(pyvenv-mode 1)

This is my minimal solution to this problem:
create a batch file like this
conda activate <yourEnv>
python -i
set (local) python-shell-interpreter pointing to the batch-file
run-python as always (C-c C-p ...)

I know this is not exactly an answer to your question. But If you JUST want to run your code, open the directory in the terminal where your files are located (e.g. cd /Downloads/Chapter01/yourfile.py) . Then, activate the environment (conda activate *your env*) and pass this command (python yourfile.py). Your code will be executed within that environment by python.
I edit remote files with emacs and run code like this in another terminal window. You may wanna open the two terminal windows side by side while debugging your code.

After activate a python virtual environment, typing `python` still get me the version in PATH

I am using windows 7. I have multiple python virtual environments. Say I added venv_1 to system PATH. In the command line, say I activate another venv_2, now the prompt line shows
(venv_2) C:\>
But if I type python here, it still runs the python in venv_1.
Is this the intended behavior?

This is not the intended behaviour, but it probably means you either made a mistake in setting up the virtual environment, or in activating it.
To be sure what version is being run, try running:
where python
Whatever the top item in the resulting list is, will be the copy of Python Windows would start. If you're right and it does actually point to venv_1, then there must be something wrong with the setup in venv_2.
By running set, you should be able to see a list of all environment variables. Check for:
PATH=<long list of directory names, it should have the venv_2\Scripts at the start>
And:
_OLD_VIRTUAL_PATH=<the same list, without that entry>
It's this simple change to the path that causes Windows to find the Python in your virtual environment first, before the one in your other virtual environment, that you added to the global path.
Note that adding the Scripts folder of the one virtual environment probably isn't a good idea, since you'd only want to use that when the corresponding virtual environment is activated and all the environment variables set accordingly.

PATH not updated correctly from conda activate in VSCode's terminal

I am using VSCodes terminal pane. I activate a conda environment. For some reason, the python command is still set to /usr/bin/python, instead of the correct path to the conda environment.
% conda activate myenv
% which python
/usr/bin/python
The correct anaconda environment directory does seem to be in the $PATH variable, but /usr/bin seems above it in priority.
When I open a standard terminal through the OS, the behavior is as I expect.
% conda activate myenv
% which python
/Users/cpl/anaconda3/envs/myenv/bin/python
Please note: I have already set the VSCode preferences key python.pythonPath to /Users/cpl/anaconda3/envs/myenv/bin/python, and I think that it works correctly. When I run a file through right-clicking and selecting Run Python File In Terminal, the correct python (from the conda environment) is executed. My problem is using the VSCode terminal directly to execute python.
My shell is zsh, and I am using OSX. Any advice?

This behavior is explained in the VSCode docs:
Why are there duplicate paths in the terminal's $PATH environment variable and/or why are they reversed?#
It sounds like VSCode will run your .zshrc twice in MacOS, conflicting with the conda-generated PATH variable definitions.
There are two solutions listed in the link above. The one that works for me is to set the VSCode setting "terminal.integrated.inheritEnv": false. The documentation warns that all of your environmental variables will be stripped if you do this. However, I find I still have my custom variables defined in the .zshrc file.
It is worth noting that recent versions of VSCode will prompt you when it detects you are using a conda environment, and suggests making this change.

I don't use zsh, but I've run into this issue in bash and I believe the cause is the same.
Conda has recently changed the "official" method of activating environments, as described in this issue: https://github.com/Microsoft/vscode-python/issues/1882
Before, you needed to modify your .bashrc/.zshrc to prepend PATH with the directory of conda's activate script, and then activate specific environments by typing source activate name_of_env. VSCode-Python activates conda terminals by sending this command to the shell — with visible echo, like you typed it yourself.
The new method is to source $HOME/anaconda3/etc/profile.d/conda.sh in .bashrc and then activate environments with conda activate name_of_env, which is the behavior you're seeing work correctly in a dedicated terminal. VSCode-Python does not yet support this, and there appear to be issues with cross-platform support on Windows that are complicating the transition.
The best solution for now is to ignore the "correct" method of conda activate and consistently use the older source activate name_of_env, which still works (if your PATH is set to include $HOME/anaconda3/bin).

A dark magic below may work:-
In my Big Sur, I added the following empty entry to my settings.json -- can be found at File(Windows)/Code(Mac)>Preferences>Settings -- click on any link stated "Edit in settings.json"
"terminal.integrated.env.osx": {
"PATH": ""
}
All the best!

If anyone else in the future ends up scratching their heads over this particular problem, I’ve found another culprit:
Terminal>Integrated>Env: Enable Persistent Sessions
I suspect what happens is that after you update system paths, VScode caches the old path in the terminal and persists it. In this case it persists the old python path rather than the new conda one.
Toggling this option off and restarting VSCode clears that cache, and the new path is loaded in. You can also toggle the option back on after you’re done.

How to set the default python path for anaconda on Linux?

I have installed anaconda on a Linux machine. I noticed that after deactivating the anaconda environment with:
source deactivate
When running:
which python
I get:
/home/user/anaconda/bin/python
Instead of
/usr/bin/python
How can I restore this setting?

The comments somewhat cover the answer to the question, but to clarify:
When you installed Anaconda you must have agreed to have it added to your PATH. You'll want to check in your ~/.bash* files and look for any export PATH= lines to check this. So Anaconda is always on your path. The source deactivate command will only deactivate "sub" Conda environments. It will never remove what is called the "root" Conda environment (the one you originally installed). If you don't want Anaconda on your PATH by default then remove it from your ~/.bash* startup files. Then when you want to use Anaconda you'll need to add it to your PATH. Or just add the specific Conda environment you are interested in to your PATH directly, and don't worry about the activate and deactivate scripts. At their core all they do is modify PATH.
I hope that helps clarify things.

Anaconda comes with its own everything, and they ask if you wish to use their software as a default when you install it by adding their bin first to your PATH variable. If you do that, you can only manually remove it later from .bashrc to undo this action.
I chose not to do it, but i made a shell script to start spyder and use the anaconda distribution when i wish to, without altering my PATH by calling spyder like this from the shell script:
PATH=/home/<... path to where i installed anaconda>/bin:$PATH spyder &
This means that i am adding their distribution's bin to the path only for the extent of running that command (spyder), otherwise my environment is unaffected by anaconda.
If i wish to add things to it, i pass an option to the shell when i source it and that triggers these actions:
PATH=/home/<... path to where i installed anaconda>/bin:$PATH
PS1='\[\033[1;34m\](A)\w:\[\033[0m\] '
so that i see (with colors!) that in this terminal i am using an altered PATH, the one with python3 and such from anaconda, etc... When done, i kill the terminal! :)

To get back to the former default, I comment out the entry setting the pathbin the .bashrc file and get these results:
$ which python
/usr/bin/python
$ python -v
python 2.7.*

If you have installed something, you want to use it before older installs, in general.
Your path is well set: your install is searched before system install.
If you want to use system python, run % /usr/bin/python.
If you don't want anaconda, just trash it (or move it somewhere ouside of path).
This may help:
% which -a python.