CONDA – managing python env

Nowadays, when starting development, there is a lot of discussion around tooling, environments and managing all of it. Previously I was working with a standard python installer or a full anaconda installation. Things mainly worked but I was not comfortable using all of it.

One of my colleagues, told me to give a try on conda. I won’t get deep in what is it, how it’s built because my only concern is being able to work easily with python for different projects.

As far as I understood, conda is like a minimal version of anaconda, just the « core » of it. The advantage is that by using only conda I’ll be able to build my environment the way I want without « broking » something on my computer. Also conda is a cross platform so I’ll be able to use it on my work computer on windows and my personal one on mac the same way. For the installation, the best way is to go to the official documentation to get it working on your specific platform.

Let’s the magic happen on the env

The main argument for using conda was the use of « conda environements » this is the thing I’ll use to separate my works and be sure that all the libraries won’t overlap and the abilities of using different version of the same library or event python.

What is an env?

The conda environment is « just » a directory somewhere on your computer where we store all our libraries including python itself. When installing, conda create a « base » environment which is not supposed to be widely used except maybe for core tooling. In my case I’ll probably wont use it.

Creating an env

Nothing is simpler than creating an env with conda. you just type:

conda create --name msgraph-env python=3.8

I think the command speaks for itself, it will create an env called « MsGraphEnv » using python version 3.8. Without other arguments, it will create the environment in the default location which is on the Miniconda3 installation folder. This can be overridden using -p flag but I found it convenient to put all my env at the same place and not spread them in each of your code directory. One disadvantage is that you can’t use the same name like « test » for every project.

The location and naming convention is your call but using VSCode as my main ide I prefer configuring everything in VSCode to plug my specific conda env to a specific VSCode workspace.

Using an env – activating

In conda even if you as a developer will « use » a specific env we first need to tell conda to use a specific one this action is called « activating » an env which will then be used until further notification.

Here is different options whether you use your favorite ide or the command line. The easiest way is to just use your command line and type

conda activate msgraph-env

Pretty straightforward you just type the « conda activate » command followed by the name of the env you want to activate.

While using VSCode the python extension let you choose env using a list of your python interpreter include your envs.

When inside an env, your prompt will be updated to let you know in which env you are working:

Exiting an env

Well, there is nothing strange here, you just have to ask for it.

conda deactivate

This command will deactivate the current environment.

Not sure wich to activate?

By the time you will work with env you’ll get to the point where you will need to check your existing env to select which one to activate. And well there is a command for that:

conda env list

Get rid of an env?

Sometimes it’s nice to clean all your mess so even if creating an environment is nice to package and make clean separation of all your lib, you will soon get messy with all your env. It’s probably a good practice to remove the envs you’re not using anymore or where just for testing purpose. Anyway it’s so easy to recreate it that it’s not a big deal and help get things cleaner.

conda env remove -n msgraph-env

Quite simple calling « conda env remove » using the -n flag to pass the name of the env you want to permanently delete.

Warning: removing an env is different than deactivating it. After removing the env you will no longer be able to activate it again. If you remove it by mistake, there is no other choice than recreating it with the exam same parameters and reinstalling all the specific libraries that were installed on it.

Considerations

You may think that it’s really cool to activate, deactivate and get fancy prefix to your prompt but what for ? Mainly it’s to be able to test new python or library version quite easily without touching your code (except maybe a specific requirement.txt).

Conda is a complete tools with lot’s of feature that i wont use for now so i didn’t whant to be « anoyed » by it when openning a command prompt for anything so i disabled the automatic activation of the base environement with this specific command:

conda config --set auto_activate_base false

I developed the first iteration of MsGraphExtract using the latest python version ie: Python 3.9 but then by adding a library and other stuff i had to test it using python 3.8 … easy peasy i just created a new env, run my pip install and that’s it !

It’s maybe not much and it’s maybe overkill to use conda just for this but for now it works and I didn’t confuse everything on my laptop while using lots of different versions of everything !