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 ...

Activcate a python virtual environment from a linux bash script

I am writing a bash script in linux that creates and activates a Python venv and then installs from a requirements.txt. Like this
python3 -m venv ~/myvenv/env
source ~/myvenv/env/bin/activate
cp requirements.txt ~/myvenv/env/requirements.txt
pip3 install -r ~/myvenv/env/requirements.txt
This doesn't work for me. It seems to create the myvenv directory but then doesnt switch in and run the requirements.txt file.
Is there a different way to activate it with source from within a bash script?

When you run script your shell spawns new process, activates it and then dies.
That's why when you get back into your shell you see unactivated one.
you can run your script just using source command. source command will load it into your active shell.
source script.sh

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

how to launch the new virtualEnv

I am trying to setup a new virtual env to work with django and flask.
installed
sudo pip install virtualenv
sudo pip install virtualenvwrapper
for some raisons, overlapping with anaconda.
This command doesn't work out.
virtualenv newThing
While this command is working out.
virtualenv -p /usr/bin/python2.7 newThing
What should I add to .bash_profile to make it working reguarly ?

That's probably the wrong question, as running a venv by default largely defeats the benefit of creating one.
To answer your question, though, you can enter a venv this way:
source newThing/bin/activate
Once you deploy this code to a server, you'll likely specify the venv to use in your WSGI conf.

If you have installed virtualenvwrapper as you say then you need to add some bits to your bash config:
# Virtualenv
source /usr/local/bin/virtualenvwrapper.sh
export WORKON_HOME="$HOME/.virtualenvs"
This ensures you source the bash script for the wrapper commands to call in bash and sets the location to use to store and access your virtual envs.
Now to create a virtualenv you can run the wrapper commmand mkvirtualenv and then the name of your desired env.
Then to switch to that env to work on your project run workon and then the name of that env.
There are a bunch of other useful wrapper commands like setting your project directory for example - this is useful when you are switching between projects which use different env.
For this try activating an venv using workon and then cd to the working directory for the project and then running setvirtualenvproject - this then remembers that directory to switch to whenever you run workon for that venv.