Aísle los proyectos con entornos virtuales

Install everything into one global Python and projects start fighting over versions. A virtual environment gives each project its own private space. 🧪

A venv is just a folder holding its own Python and packages. Activate it and pip installs land there, not system-wide.

The built-in venv module makes an environment in a folder you name. Here it lands in a folder called .venv.

Activating puts that environment first on your path, so python and pip now point inside it instead of the system.

Run which python and you should see the path to your .venv folder. That proves installs will stay isolated.

The deactivate command drops you back to the system Python. Your project packages stay safely tucked in the folder.

The .venv folder is large and machine-specific, so add it to .gitignore. Commit requirements.txt instead and rebuild anywhere.

conda creates environments too, and it can manage non-Python tools like CUDA. That makes it popular for heavy ML and GPU work.

Different Python versions can change behavior, so pin one per environment. Conda makes the Python version part of the create command.

Give each project its own environment. Then upgrading a library for one project can never silently break another.

Export your conda env to a YAML file so a teammate rebuilds the exact same setup with one command.

What is the main reason to use a separate virtual environment per project?

You can now create a venv or conda env, activate it, gitignore the folder, pin Python, and export the setup so it rebuilds anywhere. 🧰