How to install Python libraries in specific environments
I have two Anaconda installations on my computer. The first is based on Python 2.7 and the other is based on Python 3.4. The default Python version is 3.4. Moreover, I can start Python 3.4 by typing /home/eualin/.bin/anaconda3/bin/python or just python . I can do the same, but for Python 2.7, by typing /home/eualin/.bin/anaconda2/bin/python . My problem is that I don't know how to install new libraries in certain environments (either in Python 2.7 or Python 3.4). For example, when I write install seaborn, the library is installed by default under Python 3.4, when in fact I want to install it under Python 2.7. Any ideas?
EDIT
This is what I have been doing so far: the ~ / .bashrc file contains the following two blocks, of which only one is included at any given time.
# added by Anaconda 2.1.0 installer
export PATH="/home/eualin/.bin/anaconda2/bin:$PATH"
# added by Anaconda3 2.1.0 installer
#export PATH="/home/eualin/.bin/anaconda3/bin:$PATH"
Depending on which version I want to work with, I open fie, comment out the opposite block and do source ~/.bashrc
Then I install the libraries I want to use one at a time. But, is this the recommended way?
source to share
You don't need multiple distributions anaconda
for different python versions. I would suggest leaving only one.
conda
basically allows you to create environments for your various needs.
conda create -n myenv python=3.3
creates a new environment named myenv
that works with the python3.3 interpreter.
source activate myenv
switches to the newly created environment. Basically it establishes PATH
that pip
, conda
, python
and other binary files point to the correct environment and an interpreter.
conda install pip
is the first thing you might want to do. You can later use pip
it conda
to install the packages you need.
Once activated, your environment pip install <mypackage>
will point to the correct version pip
, so no need to worry too much.
You might want to create environments for different python versions or different sets of packages. Of course, you can easily switch between these environments with source activate <environment name>
.
For more examples and details, you might want to take a look at the docs .
source to share
Virtualenv seems like an obvious answer here, but I want to suggest an alternative we've been using lately: Fig is especially efficient since we also use Docker in production, but I believe using Fig as a replacement for virtualenv would be quite efficient regardless from your production environment.
source to share