The one mistake all new developers make with dependencies and how to avoid it

Every beginner does this mistake: not managing their projects dependencies separately. If you have only one project, there's no problem. With more than one, you are looking for trouble.

I'll give you an example. For the first project, you need dependency A version 1.0.0. For the second project, you need the same dependency A but version 2.0.0. To make matters worse, version 2.0.0 is not compatible with version 1.0.0.

What do you do?

The Pain of Global Dependencies

What happens when you install Python packages globally (the good old pip install)? You're making all your projects share the same environment. All dependencies are installed in the same place. This gets messy really fast! It's like watching someone try to cook a gourmet meal and bake cookies in the same pan.

So if cooking in the same pan is a bad idea, what's the alternative?

Virtual Environments to the rescue

Virtual environments are like giving each project its own private workspace. They were created for this. They allow each project to have its own dependencies. Imagine each project getting its own kitchen to experiment in. The first project can use the dependency A at version 1.0.0 in its space. The second project can use A at version 2.0.0 in its space. Both separatly. No more conflicts.

By how do you use them in practice?

Bash commands to create and use virtual environments

Let's look at how you can set up these virtual environments:

python -m venv myenv

This will create a new virtual environment (in the myenv directory). It will keep all your project dependencies.

Then, to use it you need to activate it:

source myenv/bin/activate

Now, the myenv directory will keep all installed dependencies. They are not shared with other projects.

pip install A==1.0.0

Once you are done with the project for the day, you can deactivate the virtual environment:

deactivate