Imagina que tienes dos proyectos en tu máquina. Uno necesita requests==2.28 y el otro necesita requests==2.31. Si instalas paquetes directamente con pip install sin más, ambas versiones van al mismo sitio: el site-packages global de tu instalación de Python. Y ahí está el problema: pip solo puede tener una versión de un paquete instalada a la vez. El segundo pip install simplemente sobrescribe al primero.
El proyecto que se quedó sin su versión empieza a fallar de maneras poco obvias: un método que ya no existe, un parámetro que cambió de nombre, un comportamiento silenciosamente diferente. No hay error al instalar; el error aparece cuando ejecutas el código, en producción, a las 2 AM.
Qué es exactamente un entorno virtual
Un entorno virtual es un directorio que contiene una copia ligera del intérprete Python con su propio site-packages completamente separado del sistema. Cuando activas ese entorno, python y pip apuntan a esa copia local. Todo lo que instales desde ese momento vive ahí, sin tocar nada global ni ningún otro proyecto.
La clave está en cómo Python resuelve dónde buscar paquetes. Cuando lanzas un intérprete, mira su propia ruta para construir el sys.path —la lista de directorios donde busca módulos. Un entorno virtual simplemente redirige esa búsqueda hacia su directorio local. No hay magia: es manipulación de rutas del sistema operativo combinada con un script de activación que ajusta tu PATH.
Esto también significa que si borras el directorio del entorno virtual, desaparecen sus paquetes. Y eso es exactamente lo que quieres: los entornos son desechables y reproducibles, nunca preciosos.
Cuándo usar un entorno virtual
Siempre. Desde el primer touch main.py. No cuando el proyecto “sea suficientemente grande”, no cuando “empiece a tener dependencias”. El momento correcto es antes de instalar el primer paquete externo.
La razón práctica: si esperas, ya contaminaste tu entorno global con paquetes que “solo eran para esta prueba rápida”. Después esos paquetes están ahí para siempre, invisibles, hasta que otro proyecto los pisa o hasta que mueves tu código a otra máquina y descubres que no funciona porque dependías de algo que tenías instalado globalmente sin saberlo.
# project_a/main.py
# Este proyecto necesita requests 2.28 por una API legacy
import sys
import requests
def check_environment():
# sys.prefix muestra la raíz del entorno Python activo.
# Si es diferente de sys.base_prefix, estás dentro de un venv.
in_venv = sys.prefix != sys.base_prefix
print(f"Usando entorno virtual: {in_venv}")
print(f"Directorio del entorno: {sys.prefix}")
print(f"Versión de requests: {requests.__version__}")
print(f"Ubicación del paquete: {requests.__file__}")
check_environment()
Para verlo en acción, el flujo completo desde la terminal:
# Crear el entorno virtual en un subdirectorio llamado .venv python -m venv .venv # Activar (Linux/macOS) source .venv/bin/activate # Activar (Windows) .venv\Scripts\activate # Tu prompt cambia: (.venv) usuario@máquina:~/project_a$ # Ahora pip instala SOLO en este entorno pip install "requests==2.28.2" # Ejecutar el script python main.py
Salida esperada:
Usando entorno virtual: True Directorio del entorno: /home/usuario/project_a/.venv Versión de requests: 2.28.2 Ubicación del paquete: /home/usuario/project_a/.venv/lib/python3.11/site-packages/requests/__init__.py
Qué nos dice ese output
El chequeo sys.prefix != sys.base_prefix es la forma canónica de detectar si estás dentro de un entorno virtual. sys.base_prefix apunta siempre a la instalación real de Python del sistema y nunca cambia. sys.prefix sí cambia cuando activas un venv. Si son iguales, estás en el Python global.
La ruta de requests.__file__ confirma el aislamiento: el paquete vive dentro de .venv/lib/, no en ningún directorio del sistema. Ahora puedes crear project_b/ con su propio .venv e instalar requests==2.31 ahí. Los dos proyectos coexisten sin conflicto porque cada uno tiene su propio universo de paquetes.
Fíjate también en que el directorio .venv suele excluirse del control de versiones (añádelo a .gitignore). Lo que sí se versiona es el archivo requirements.txt que describes con pip freeze > requirements.txt. Eso es lo que permite que otra persona —o tú mismo en otra máquina— recree el entorno exacto con pip install -r requirements.txt. El directorio es efímero; el manifiesto de dependencias es lo que importa.
Errores que debes conocer
Error: instalar paquetes con pip sin activar el entorno primero, creyendo que porque creaste el .venv ya está activo.
# ❌ Incorrecto: el entorno existe pero no está activo python -m venv .venv pip install flask # Va al Python global, no al venv # ✅ Correcto: activar antes de instalar python -m venv .venv source .venv/bin/activate pip install flask # Ahora sí va a .venv/lib/
El prompt de tu terminal no muestra el nombre del entorno entre paréntesis si no está activo; úsalo como indicador visual antes de cualquier pip install.
Error: versionar el directorio .venv completo en lugar del archivo de dependencias.
# ❌ Incorrecto: subir el directorio binario al repositorio git add .venv/ # ✅ Correcto: registrar solo el manifiesto reproducible pip freeze > requirements.txt git add requirements.txt
El directorio .venv contiene rutas absolutas y binarios del sistema operativo; no es portable. requirements.txt es texto plano que funciona en cualquier máquina.
N° 69