Conda tip from a `requirements.txt` type of person

I am a requirements.txt (venv/pipenv) type of person. I have my reasons for that, but I won't mention these reasons here (well, technically, problems such as the one described in this post is one of these reasons).

At some point, I finally need to get familiar with conda. The first surprise: installing conda on linux is not as simple as sudo apt-get install ... or sudo pip install .... You need to download a bash installer and run it. But I was cool with that. After choosing some installation options, and adding conda to the PATH (it was also not mentioned explicitly in the installation guides that you have to do it [1][2]) I was ready to go.

In the repository of a project I wanted to start working on, I had an environment.yml file (which is an equivalent of a requirements.py). Now comes the most tricky part:

The official documentation says:

Create the environment from the environment.yml file:

conda env create -f environment.yml

Ok, so I did run this command, but I got the following error:

CondaValueError: prefix already exists: /home/user/anaconda3

That is unfortunate. Anyways, I googled the error, and here's what I found:

Conda bug: CondaValueError: prefix already exists: /home/user/anaconda2

Long story short, if your .yml file have an empty name field, you have to explicitly specify environment name when creating the environment with conda command, like that:

conda env create -f environment.yml -n environmentName

I followed this advice and my environment has been successfully created.

To sum up, my tip, as a requiements.txt type of person, is that conda is less "user friendly" in the sense that you have to be more aware what is going on, in terms of command execution and naming of the environments. To compare this to the pipenv's behavior: by default pipenv creates a directory with your virtual environment in the ~/local/share/virtualenvs/ which comprises of the name of the directory where you invoke pipenv command, and a hash. So, the entry level is lower, you just run the command and it works, but then you have to know where the environment is located (you get that information also in the pipenv's output log). Conda, on the other hand, is harder to use because of the more enigmatic error information, and the conventions you have to be aware of, before even running the command.