Conda & Dealing with Conflicting Python(s) in your system

How all pythons and condas can live together.

:: originally posted on ::

The problem

I took up a course on robotics using Robot Operating System (ROS). However, I always keep a miniconda3 installation to handle my data science adventures and respective dependencies. To clarify, it installs conda, a general purpose package manager - although really I only use it to install python libraries - and python 3.6.

What happens is that ROS uses the system python - i.e. python 2.7. The problem arises if you set your “python path” to default to that of miniconda3, a procedure which is automated when you accept that the miniconda3 installer adds the following line to your .bashrc file.

export PATH="/home/user/miniconda3/bin:$PATH"

In other words, everytime you open a shell, your system sets the python interpreter to that of miniconda3, which is version 3.6. So everytime I ran something from ROS, it would crash running python scripts that were written in version 2.7, namely due to syntax differences on the print command between the two versions.

The solution - meet symlinks

After reading conda’s documentation on the subject, I decided to test my ability to implement their suggested solution, which is to:

  • remove miniconda3 from the PATH
  • create symlinks to three components of miniconda3
    • conda
    • activate
    • deactivate
  • add these symlinks to the PATH

To remove miniconda3 from the PATH, one simply has to comment out or delete the aforementioned line in the .bashrc file, using some text editor like nano for example.

Now that that is done, let us create symlinks. A symlink, for the purpose of this post, is like a pointer to some other executable file and will function as a command. I created a specific folder (.symlinks) just for that.

mkdir .symlinks
cd .symlinks

Now that we’re in the .symlinks folder, let’s actually create symlinks.

ln -s /home/user/miniconda3/bin/conda conda
ln -s /home/user/miniconda3/bin/activate activate
ln -s /home/user/miniconda3/bin/deactivate deactivate

To verify that they were created, run ls -l (list files) in the .symlinks folder, you’ll be able to see the pointers.

lrwxrwxrwx 1 user user 34 Nov  9 14:08 activate -> /home/user/miniconda3/bin/activate
lrwxrwxrwx 1 user user 31 Nov  9 14:10 conda -> /home/user/miniconda3/bin/conda
lrwxrwxrwx 1 user user 36 Nov  9 14:08 deactivate -> /home/user/miniconda3/bin/deactivate

At last, we add the .symlinks folder to the path. But we want to have these symlink commands automatically available every time we open a new shell. The answer is to “add” them to the script which is run everytime a shell is opened: the .bashrc file. So, add this line to the said file.

export PATH="/home/user/.symlinks:$PATH"

For the changes to take effect, you may close and reopen the terminal, but to feel like a pro without doing that move, run source .bashrc.

Now, if you run python --version you will get the system python back.

user@ryzen:~$ python --version
Python 2.7.12

If you want to use python 3.6 from the root conda environment, do

user@ryzen:~$ source activate root
(root) user@ryzen:~$ python --version
Python 3.6.3 :: Anaconda, Inc.

As you can see from the python --version bit, we’re now using the 3.6 interpreter. If I want to activate the environment where I installed data science libraries I’d run source activate ds.

Now that the newer interpreter is activated, you can run scripts that were written for that interpreter. Anyways, if you need to revert back to the system interpreter (2.7) on the current shell, then run

(root) user@ryzen:~$ source deactivate
user@ryzen:~$ python --version
Python 2.7.12

As you can see, we’re back to 2.7. So you can run software that runs on this version with no problems, and switch back to your 3.6 antics whenever you want. 😄