Develop Reference

Get a fresh bash without conda

is there a way to easily switch from conda environments to my system's native python environment? When I have conda activated, and I run bash or exec bash it doesn't seem to work, and when I run python it uses conda's python and it's not using the system python path. The only way I've been able to get this to work is by restarting the terminal entirely. Is there a faster way to do this?
(I've actually removed the conda init block from my ~/.bashrc and I run it manually every time I want to use conda's python.)

You have two options:
Just deactivate the base environment:
(base) $ conda deactivate
$
Configure your conda to not activate the base environment on startup.
(base) $ conda config --set auto_activate_base false
<restart shell>
$
# use the system python
$ python
# to use conda you'll need to activate it first
$ conda activate
(base) $ python

The conda command you're looking for is deactivate.
Suppose you have activated the myproject environment.
$ conda deactivate
Now your environment is base, as seen by which python,
or conda info --envs.
$ conda deactivate
Now you're not using conda at all, and which python shows the system
interpreter, likely /usr/bin/python.

This may be a bit of a hack, but what about adding an alias pointing to the system python before the conda block in .bashrc? Assuming you don't want to use "conda deactivate" and lose the environment completely.
alias syspython=`which python`
# >>> conda initalize >>>
...
You should then be able to use the system python in a conda env like so:
syspython file.py ...

run a Python script with Conda dependencies on a Docker container [duplicate]

Scenario
I'm trying to setup a simple docker image (I'm quite new to docker, so please correct my possible misconceptions) based on the public continuumio/anaconda3 container.
The Dockerfile:
FROM continuumio/anaconda3:latest
# update conda and setup environment
RUN conda update conda -y \
&& conda env list \
&& conda create -n testenv pip -y \
&& source activate testenv \
&& conda env list
Building and image from this by docker build -t test . ends with the error:
/bin/sh: 1: source: not found
when activating the new virtual environment.
Suggestion 1:
Following this answer I tried:
FROM continuumio/anaconda3:latest
# update conda and setup environment
RUN conda update conda -y \
&& conda env list \
&& conda create -y -n testenv pip \
&& /bin/bash -c "source activate testenv" \
&& conda env list
This seems to work at first, as it outputs: prepending /opt/conda/envs/testenv/bin to PATH, but conda env list as well ass echo $PATH clearly show that it doesn't:
[...]
# conda environments:
#
testenv /opt/conda/envs/testenv
root * /opt/conda
---> 80a77e55a11f
Removing intermediate container 33982c006f94
Step 3 : RUN echo $PATH
---> Running in a30bb3706731
/opt/conda/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
The docker files work out of the box as a MWE.
I appreciate any ideas. Thanks!

Using the docker ENV instruction it is possible to add the virtual environment path persistently to PATH. Although this does not solve the selected environment listed under conda env list.
See the MWE:
FROM continuumio/anaconda3:latest
# update conda and setup environment
RUN conda update conda -y \
&& conda create -y -n testenv pip
ENV PATH /opt/conda/envs/testenv/bin:$PATH
RUN echo $PATH
RUN conda env list

Method 1: use SHELL with a custom entrypoint script
EDIT: I have developed a new, improved approach which better than the "conda", "run" syntax.
Sample dockerfile available at this gist. It works by leveraging a custom entrypoint script to set up the environment before execing the arguments of the RUN stanza.
Why does this work?
A shell is (put very simply) a process which can act as an entrypoint for arbitrary programs. exec "$#" allows us to launch a new process, inheriting all of the environment of the parent process. In this case, this means we activate conda (which basically mangles a bunch of environment variables), then run /bin/bash -c CONTENTS_OF_DOCKER_RUN.
Method 2: SHELL with arguments
Here is my previous approach, courtesy of Itamar Turner-Trauring; many thanks to them!
# Create the environment:
COPY environment.yml .
RUN conda env create -f environment.yml
# Set the default docker build shell to run as the conda wrapped process
SHELL ["conda", "run", "-n", "vigilant_detect", "/bin/bash", "-c"]
# Set your entrypoint to use the conda environment as well
ENTRYPOINT ["conda", "run", "-n", "myenv", "python", "run.py"]
Modifying ENV may not be the best approach since conda likes to take control of environment variables itself. Additionally, your custom conda env may activate other scripts to further modulate the environment.
Why does this work?
This leverages conda run to "add entries to PATH for the environment and run any activation scripts that the environment may contain" before starting the new bash shell.
Using conda can be a frustrating experience, since both tools effectively want to monopolize the environment, and theoretically, you shouldn't ever need conda inside a container. But deadlines and technical debt being a thing, sometimes you just gotta get it done, and sometimes conda is the easiest way to provision dependencies (looking at you, GDAL).

Piggybacking on ccauet's answer (which I couldn't get to work), and Charles Duffey's comment about there being more to it than just PATH, here's what will take care of the issue.
When activating an environment, conda sets the following variables, as well as a few that backup default values that can be referenced when deactivating the environment. These variables have been omitted from the Dockerfile, as the root conda environment need never be used again. For reference, these are CONDA_PATH_BACKUP, CONDA_PS1_BACKUP, and _CONDA_SET_PROJ_LIB. It also sets PS1 in order to show (testenv) at the left of the terminal prompt line, which was also omitted. The following statements will do what you want.
ENV PATH /opt/conda/envs/testenv/bin:$PATH
ENV CONDA_DEFAULT_ENV testenv
ENV CONDA_PREFIX /opt/conda/envs/testenv
In order to shrink the number of layers created, you can combine these commands into a single ENV command setting all the variables at once as well.
There may be some other variables that need to be set, based on the package. For example,
ENV GDAL_DATA /opt/conda/envs/testenv/share/gdal
ENV CPL_ZIP_ENCODING UTF-8
ENV PROJ_LIB /opt/conda/envs/testenv/share/proj
The easy way to get this information is to call printenv > root_env.txt in the root environment, activate testenv, then call printenv > test_env.txt, and examine
diff root_env.txt test_env.txt.

Conda: Creating a virtual environment

I'm trying to create a virtual environment. I've followed steps from both Conda and Medium.
Everything works fine until I need to source the new environment:
conda info -e
# conda environments:
#
base * /Users/fwrenn/anaconda3
test_env /Users/fwrenn/anaconda3/envs/test_env
source ~/anaconda3/bin/activate test_env
_CONDA_ROOT=/Users/fwrenn/anaconda3: Command not found.
Badly placed ()'s.
I can't figure out the problem. Searching on here has solutions that say adding lines to your bash_profile file, but I don't work in Bash, only C shell (csh). It looks like it's unable to build the directory path in activate.
My particulars:
OS X
Output of python --version:
Python 3.6.3 :: Anaconda custom (64-bit)
Output of conda --version:
conda 4.4.7

I am not sure what causes the problem in your case, but code below works for me without any issues (OS X, the same version of Conda as yours).
Creation of the environment
conda create -n test_env python=3.6.3 anaconda
Some explanation of the documentation of conda create is not clear:
-n test_env sets name of the environment to test_env
python=3.6.3 anaconda says that you want to use python in version 3.6.3 in this environment (exactly the one you have, and you can use a different one if you need it) and package anaconda. You can put all the things you need there, separated with spaces, e.g., sqlite matplotlib requests and specify their versions the same way as for python.
Activation
conda activate test_env
Deactivation
conda deactivate
Getting rid of it
conda remove -n test_env --all

Check if Conda is installed
conda -V
Check if Conda is up to date
conda update conda
Create a virtual environment
conda create -n yourenvname python=x.x anaconda
Activate your virtual environment
source activate yourenvname
Install additional Python packages to a virtual environment
conda install -n yourenvname [package]
Deactivate your virtual environment
source deactivate
Delete the virtual environment
conda remove -n yourenvname --all

I was able to solve my problem. Executing the source activate test_env command wasn't picking up my .bash_profile, and I normally work in tcsh. Simply starting a subprocess in Bash was enough to get activate working. I guess I assumed, incorrectly, that the activate command would start a child process in Bash and use Bash environment variables.
> conda info -e
> # conda environments:
> #
> base * ~/anaconda3
> test_env ~/anaconda3/envs/test_env
> bash
~$ source ~/anaconda3/bin/activate test_env
(test_env) ~$
(test_env) ~$ conda info -e
# conda environments:
#
test_env * ~/anaconda3/envs/test_env
root ~/anaconda3

How do I run globally installed Jupyter from within virtual environments?

I'm trying to run Jupyter notebooks with a globally installed version of Jupyter from within virtual environments (using virtualenvwrapper, because I want to manage versions of installed packages). And I do not what to use Anaconda.
The problem is when I run jupyter notebook from within the virtualenv, it cannot find the packages installed in the env, it only finds the packages installed globally.
How do I set up Jupyter to check for packages installed within the virtual environment instead of globally?
Here is what I get when I run which python and which jupyter:
globally:
which python >>> /usr/local/bin/python
which jupyter >>> /usr/local/bin/jupyter
from within virtualenv:
which python >>> /Users/brianclifton/.virtualenvs/test/bin/python
which jupyter >>> /usr/local/bin/jupyter
running jupyter notebook from within the virtualenv:
which python >>> /usr/local/bin/python
which jupyter >>> /usr/local/bin/jupyter
Also, here is my .bash_profile:
export VISUAL=vim
export EDITOR="$VISUAL"
export PS1="\\[\[\e[38;5;94m\][\u] \[\e[38;5;240m\]\w:\[\e[m\] \$(__git_ps1 '(%s)')$ "
export CLICOLOR=1
export LSCOLORS=ExFxBxDxCxegedabagacad
export PATH=/usr/local/bin/python:/usr/local/bin:$PATH
alias ls='ls -GFh'
alias pserv="python -m SimpleHTTPServer"
alias ipynb="jupyter notebook"
export WORKON_HOME=/Users/brianclifton/.virtualenvs
export PROJECT_HOME=/Users/brianclifton/dev
source /usr/local/bin/virtualenvwrapper.sh
if [ -f $(brew --prefix)/etc/bash_completion ]; then
. $(brew --prefix)/etc/bash_completion
fi
alias branch='git rev-parse --abbrev-ref HEAD'
function frameworkpython {
if [[ ! -z "$VIRTUAL_ENV" ]]; then
PYTHONHOME=$VIRTUAL_ENV /usr/local/bin/python "$#"
else
/usr/local/bin/python "$#"
fi
}

Another solution from virtualenv doc
workon test
pip install ipykernel
python -m ipykernel install --prefix=/usr/local --name test-kernel
Then your kernel should appear when you run jupyter from your other virtualenv, and all the packages installed in test would be available from it. Change prefix value according to the doc if you prefer a per-user installation instead of system-wide

One possible solution is to prefix your virutalenv's bin directory to your path. This way jupyter will find the virtualenv's libraries. You can do this by running export PATH:`which python`:$PATH after you activate your environment. It would be easy enough to alias.
However, a better solution may be to add this line to the postactivate hook/script. To find the location of this script do ls $WORKON_HOME after activate virtualenvwrapper and edit $WORKON_HOME/<virtualenv_name>/bin/postactivate.

conda how do I activate environments

I am struggling to activate conda environments I have created on mac os x.
Here are the environment that I have created.
$: conda env list
# conda environments:
#
py34 /Students/rt12083/anaconda3/envs/py34
py35 /Students/rt12083/anaconda3/envs/py35
root * /Students/rt12083/anaconda3
When I try to activate them I get the following error:
$: source activate py34
activate: No such file or directory.
When i run the command which activate I get the following:
which activate
/Students/rt12083/anaconda3/bin/activate
my path variable is:
garnet: echo $PATH
/sw/bin:/sw/sbin:.:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin:/usr/local/bin:/ Developer/Tools:/usr/local/GMT4.5.7/bin:/usr/local/TauP/bin:/usr/local/SU/bin:/usr/local/sac/bin:/usr/local/sac/iaspei:/usr/local/sac/macros:/Students/rt12083/anaconda3/bin
What do I need to do to activate the environments?

Your path seems to be missing the root anaconda directory. when i echo $Path (where username is replacing my actual username) i have the following:
/Users/username/anaconda/bin:/Users/username/anaconda/bin:/Users/username/anaconda/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
in my bash_profile (or zshrc file etc...) I added:
export PATH="/Users/username/anaconda/bin:$PATH"
I use iterm2 with zsh, although this probably applies to more general cases.
On OSX Sierra with Anaconda3 4.4.0 the path is now:
export PATH="/anaconda/bin:$PATH"

use the following
conda create -n your_Env_Name
Then activate it with:
conda activate your_Env_Name

I use miniconda2, so not sure if this will work but:
open terminal & navigate to wherever you have conda installed.
for me its
/Users/username/miniconda 2
and then do source activate env_name
and then you can navigate back to your development directory