3.2pip, entornos virtuales (venv) y gestión de dependencias
Lo esencial en 30 segundos
- El global lo mezcla todo : dos proyectos que exigen dos versiones de un mismo paquete son imposibles juntos — cada proyecto merece su entorno aislado.
- El ritual venv + pip : python -m venv .venv, activar, pip install, pip freeze > requirements.txt — el intérprete y pip apuntan entonces al venv.
- El .venv nunca se versiona, el requirements siempre : versiones fijadas, reconstrucción probada por pip install -r — el proyecto es portable.
Mini-caso hilado — Nabil sale del infierno de las versiones
Nabil, analista de datos junior en Alger, instala todo en global : su análisis de ventas exige una versión reciente de una librería, pero el reporting de un colega se rompe en cuanto actualiza. Crea un venv por proyecto (python -m venv .venv), activa, instala, fija con pip freeze > requirements.txt, añade .venv al .gitignore. Eliminado y luego reconstruido vía pip install -r, cada proyecto recupera exactamente sus versiones.
Este mismo caso vuelve en el curso, el esquema, el guion y el reto 48h.
1. El caos del global y la burbuja venv
La fuerza de Python es su catálogo PyPI, instalado vía pip (pip install pandas). Pero instalarlo todo en global mezcla las dependencias de todos los proyectos : el proyecto A exige una versión, el B otra — imposible juntos, es el infierno de las dependencias. Desde el segundo proyecto, el aislamiento es no negociable.
La solución es el entorno virtual (venv) : una carpeta aislada con su Python y sus paquetes, sin tocar los demás proyectos. Se crea (python -m venv .venv), se activa (Windows : .venv\Scripts\activate ; macOS/Linux : source .venv/bin/activate) — el prompt cambia, python y pip apuntan entonces al venv. Nabil crea un venv para el análisis de ventas, otro para el reporting : cada uno vive su vida.
2. Fijar, compartir, reconstruir : requirements.txt
Un venv solo no basta : hace falta el contrato de las versiones. pip freeze > requirements.txt exporta dependencias y versiones fijadas ; pip install -r requirements.txt las reinstala idénticas en otro lado. La carpeta .venv NUNCA se versiona (voluminosa, específica de la máquina, vía .gitignore) ; el requirements.txt SIEMPRE (ligero, compartible).
La prueba de verdad de Nabil : eliminar el .venv y reconstruirlo en un comando — si el análisis corre, el proyecto es portable. Comprobar con pip list que la librería está bien en ESTE venv, y seleccionar el intérprete del .venv en el editor. Tras cada añadido, se vuelve a fijar para mantener el contrato al día.
🔎 Ejemplo concreto — Ritual completo del proyecto aislado
Nabil aísla su análisis de ventas, luego lo reconstruye en otro lado.
python -m venv .venv
.venv\Scripts\activate
pip install requests
pip freeze > requirements.txt
deactivateLectura : crear, activar, instalar, fijar — el requirements se vuelve el contrato.
Lección : en otro lado, recrear el venv y luego pip install -r requirements.txt restaura idéntico.
Vocabulario de la sección
- pip
- Gestor de paquetes de Python : pip install nom descarga e instala una biblioteca desde PyPI en el entorno activo.
Ejemplo sencillo: El pip install requests de Nabil en su venv de análisis.
Lo que no es: descargar un ZIP y colocarlo a mano.
Reflejo: comprobar siempre el venv activo antes de pip install.
- PyPI
- Depósito central de bibliotecas terceras Python : cientos de miles de paquetes instalables.
Ejemplo sencillo: El catálogo donde Nabil encuentra requests y pandas.
Lo que no es: la biblioteca estándar incluida de oficio.
Reflejo: estándar primero, PyPI después.
- Entorno virtual (venv)
- Carpeta aislada con su Python y sus paquetes, propia de un proyecto, sin interferir con los demás.
Ejemplo sencillo: El .venv analyse-ventes de Nabil, separado del reporting.
Lo que no es: una instalación global compartida por todos los proyectos.
Reflejo: un venv por proyecto, desde el inicio.
- Activación
- Volver un venv activo en el terminal para que python y pip apunten a él (invitación modificada).
Ejemplo sencillo: El activate de Nabil antes de cada sesión de análisis.
Lo que no es: trabajar olvidando activar, o sea en global.
Reflejo: activar primero, instalar después.
- requirements.txt
- Lista de dependencias y versiones : pip freeze la exporta, pip install -r las reinstala idénticas.
Ejemplo sencillo: El contrato versionado que Nabil comparte en Alger.
Lo que no es: la carpeta .venv versionada en Git.
Reflejo: fijar tras cada añadido, reconstruir para probar.
En la práctica — Aislar un proyecto con venv y pip
- Cread un venv (python -m venv .venv) y luego activadlo ; comprobad que la invitación del terminal ha cambiado.
- Instalad una biblioteca (pip install requests) y comprobad con pip list que está en ESTE venv, no en global.
- Fijad con pip freeze > requirements.txt ; abrid el archivo y observad las versiones fijadas.
- Desactivad (deactivate), eliminad el venv, recreadlo y reinstalad vía pip install -r requirements.txt.
Guion listo para decir — presentar su entorno (30 s)
« Cada proyecto tiene su venv : creado por python -m venv .venv, activado antes de toda install, dependencias fijadas por pip freeze en requirements.txt versionado, .venv ignorado por Git. Probado por eliminación y luego pip install -r : reconstrucción idéntica. »
Para decir en revisión ; mostrar el prompt activado y el requirements.
Modelo copiar-pegar — ritual venv + requirements
python -m venv .venv
.venv\Scripts\activate
pip install requests
pip list
pip freeze > requirements.txt
deactivate
python -m venv .venv
.venv\Scripts\activate
pip install -r requirements.txtIndependiente
Un venv + un requirements fijado basta para compartir el análisis sin fricción.
PYME en Alger
Nabil duplica el ritual : un venv ventas, un venv reporting, cero conflicto.
Equipo de producto
Imponer .venv ignorado + requirements versionado para installs idénticas en todas partes.
Principiante
Esta semana : un venv, una install, un freeze, una reconstrucción.
✓ Buenas prácticas
- Crear un venv por proyecto desde el primer pip install.
- Fijar tras cada añadido (freeze) y mantener el requirements versionado.
- Reconstruir (eliminar + install -r) para probar la reproducibilidad.
✗ Errores frecuentes
- Instalarlo todo en global (conflictos de versiones garantizados).
- Versionar el .venv (MB inútiles, específico de la máquina).
- Compartir un requirements sin versiones fijadas (deriva silenciosa).
Puntos clave
- pip INSTALA desde PyPI en el entorno ACTIVO — comprobar la activación primero.
- Un VENV aísla las dependencias POR PROYECTO : fin de los conflictos de versiones.
- requirements.txt (freeze / install -r) vuelve el proyecto REPRODUCIBLE en todas partes.
- .venv NUNCA versionado (.gitignore) ; requirements SIEMPRE versionado, reconstruido como prueba.
Reto 48h — aplica mañana
Cread 1 venv, instalad 1 paquete, fijad el requirements, y luego reconstruid vía install -r.
- Cada proyecto tiene su venv activado antes de instalar.
- Mi requirements fija las versiones exactas.
- Mi .venv está ignorado, mi reconstrucción funciona.
Preguntas frecuentes
¿Por qué no instalarlo todo en global, que es más simple?
Porque dos proyectos exigirán pronto versiones incompatibles de una misma biblioteca : es el infierno de las dependencias. Un venv por proyecto da a cada uno exactamente lo que necesita y vuelve el proyecto compartible idéntico vía requirements.txt.
¿Hay que versionar la carpeta .venv en Git?
No, nunca : voluminosa y específica de la máquina. Se excluye vía .gitignore y solo se comparte requirements.txt — cada colaborador recrea su venv por pip install -r.
¿Qué se comparte en Git para reproducir el entorno?