pip y entornos virtuales en Python
La biblioteca estándar de Python es enorme, pero para la mayoría de trabajos reales necesitas algo más: una librería HTTP que sea un placer de usar, un motor de análisis de datos, un framework web, un cliente de base de datos. Todo eso existe, está libre, y está a un comando de distancia. pip install requests. Pero sin entender los entornos virtuales, ese comando puede convertirse en la fuente de problemas que tardan horas en diagnosticar.
El ecosistema de paquetes Python
Python tiene una biblioteca estándar que cubre las necesidades básicas: ficheros, red, fechas, matemáticas, JSON, expresiones regulares. Pero el verdadero poder de Python viene del ecosistema de paquetes de terceros: más de 550.000 paquetes disponibles en PyPI (Python Package Index), el repositorio oficial.
Para gestionar esos paquetes existe pip, el gestor de paquetes estándar de Python. Con pip puedes instalar, actualizar, desinstalar y listar paquetes en segundos. Viene incluido con cualquier instalación de Python moderna.
pip es tu acceso a ese taller: con un comando traes exactamente la herramienta que necesitas —requests para HTTP, pandas para datos, Flask para web— sin tener que construirla desde cero. Fuente: Pexels (licencia libre).La diferencia con los gestores de paquetes de otros lenguajes es que Python separa claramente el repositorio central (PyPI) del gestor de instalación (pip). PyPI es el supermercado; pip es el carrito de la compra.
pip install: tu primer paquete
Antes de hablar de entornos virtuales, lo más básico: cómo instalar un paquete y cómo verificar que funciona.
# Instalar un paquete
pip install requests
# Instalar una versión específica
pip install requests==2.31.0
# Instalar con restricción de versión
pip install "requests>=2.28,<3"
# Actualizar a la última versión
pip install --upgrade requests
# Desinstalar
pip uninstall requests
# Ver información del paquete instalado
pip show requests
# Name: requests
# Version: 2.31.0
# Location: /home/usuario/.local/lib/python3.11/site-packages
# Requires: certifi, charset-normalizer, idna, urllib3
Tras instalar requests, puedes usarlo inmediatamente:
import requests
respuesta = requests.get('https://api.github.com/repos/python/cpython')
datos = respuesta.json()
print(f"Python tiene {datos['stargazers_count']:,} estrellas en GitHub")
print(f"Último push: {datos['pushed_at']}")
Listar paquetes instalados
# Ver todos los paquetes instalados
pip list
# Ver paquetes desactualizados
pip list --outdated
# Formato para requirements.txt
pip freeze
# requests==2.31.0
# urllib3==2.1.0
# certifi==2024.2.2
# ...
pip check verifica que todas las dependencias de los paquetes instalados están satisfechas. Si algún paquete requiere una versión específica de otro que no está instalada, pip check lo detecta. Útil para diagnosticar entornos corrompidos.
El problema: dependency hell
Imagina que trabajas en dos proyectos diferentes. El proyecto A usa una versión antigua de Django (3.2 LTS) porque tiene código que no es compatible con versiones nuevas. El proyecto B está en Django 5.0. Si instalas los dos en el Python global del sistema, es imposible: solo puede haber una versión de Django instalada a la vez.
Esto se llama dependency hell (infierno de dependencias), y es uno de los problemas más clásicos en el desarrollo de software. Python lo resuelve con los entornos virtuales: un directorio autocontenido que tiene su propio intérprete Python, su propio pip, y sus propios paquetes instalados, completamente aislado del Python global y de otros entornos virtuales.
# Sin entornos virtuales: imposible tener las dos versiones
pip install django==3.2 # proyecto A
pip install django==5.0 # ← rompe el proyecto A
# Con entornos virtuales: cada proyecto tiene el suyo
proyecto_a/.venv/ → Django 3.2
proyecto_b/.venv/ → Django 5.0
# Ambos coexisten sin conflicto
requirements.txt permite reproducir el entorno idéntico en cualquier máquina. Infografía: Ciberaula.Crear y activar un entorno virtual
El módulo venv viene incluido en Python 3.3+ y es la herramienta estándar para crear entornos virtuales. El flujo es siempre el mismo: crear → activar → trabajar → desactivar.
Crear el entorno
# Crear un entorno virtual llamado .venv en el directorio actual
python -m venv .venv
# Con una versión específica de Python (si tienes varias instaladas)
python3.11 -m venv .venv
# Con acceso a los paquetes del sistema (útil en algunos casos)
python -m venv .venv --system-site-packages
El nombre .venv (con punto inicial) es la convención más extendida: el punto lo hace oculto en Unix, y la mayoría de herramientas (VS Code, PyCharm, GitHub Copilot) lo reconocen automáticamente. Algunas personas prefieren env o venv sin punto; en equipos, lo importante es que todos usen el mismo nombre.
Activar el entorno
# macOS / Linux
source .venv/bin/activate
# Windows (Command Prompt)
.venv\Scripts\activate
# Windows (PowerShell)
.venv\Scripts\Activate.ps1
Cuando el entorno está activo, el prompt del terminal muestra el nombre entre paréntesis: (.venv) usuario@host:~/proyecto$. Ahora python y pip apuntan al entorno virtual, no al global.
# Verificar que estás en el entorno correcto
which python # → /home/usuario/proyecto/.venv/bin/python
which pip # → /home/usuario/proyecto/.venv/bin/pip
python --version # → Python 3.11.x (la versión del venv)
Desactivar
deactivate # vuelve al Python global del sistema
Instalar y gestionar paquetes en el entorno
Con el entorno activado, pip install instala en el entorno virtual, no en el sistema. El proceso es idéntico al que ya conoces, pero con el entorno activado.
# Con el entorno activado: (.venv) $
pip install requests pandas flask
# Ver lo que hay instalado (solo lo del venv, más limpio)
pip list
# Package Version
# ---------- -------
# flask 3.0.2
# pandas 2.2.1
# requests 2.31.0
# ...
pip show flask
# Name: Flask
# Version: 3.0.2
# Location: /home/usuario/proyecto/.venv/lib/python3.11/site-packages
# Desinstalar (solo afecta al venv)
pip uninstall requests
Version specifiers: controlar versiones
En un requirements.txt de producción, la versión importa. Los specifiers de PEP 440 te dan control preciso:
# Versión exacta (máxima reproducibilidad, mínima flexibilidad)
requests==2.31.0
# Mínimo 2.28, lo que sea de la rama 2.x (recomendado para librerías)
requests>=2.28,<3
# Compatible release: >=2.28, <3 (la rama del minor no cambia)
requests~=2.28
# Excluir una versión con bug conocido
requests!=2.30.0,>=2.28
# Múltiples condiciones
"flask>=3.0,<4,!=3.0.1" # excluir versión con vulnerabilidad
2.10 es mayor que 2.9. pip lo sabe, pero a veces confunde a los humanos. requests==2.10.0 no es requests==2.1.0.
requirements.txt: congelar y reproducir
requirements.txt es el fichero que hace que un entorno Python sea reproducible. Es la lista de todos los paquetes que tu proyecto necesita, con sus versiones, de forma que cualquier desarrollador (o servidor de CI/CD) pueda recrear el entorno exacto con un solo comando.
# Generar requirements.txt desde el entorno actual (versiones exactas)
pip freeze > requirements.txt
# Instalar todo lo que hay en requirements.txt
pip install -r requirements.txt
# En una máquina nueva, el flujo completo:
git clone https://github.com/usuario/mi_proyecto.git
cd mi_proyecto
python -m venv .venv
source .venv/bin/activate # (o .venv\Scripts\activate en Windows)
pip install -r requirements.txt # reproduce el entorno exacto
python main.py # funciona
Formato del fichero
## requirements.txt generado por pip freeze
certifi==2024.2.2
charset-normalizer==3.3.2
flask==3.0.2
idna==3.6
jinja2==3.1.3
markupsafe==2.1.5
requests==2.31.0
urllib3==2.2.1
werkzeug==3.0.1
Separar por entorno (patrón avanzado)
En proyectos medianos o grandes es habitual separar las dependencias por entorno:
requirements/
├── base.txt # dependencias de todos los entornos
├── dev.txt # base + herramientas de desarrollo
└── prod.txt # base + librerías de producción
# requirements/base.txt
requests>=2.28,<3
flask~=3.0
# requirements/dev.txt
-r base.txt # incluye todo base.txt
pytest>=7.0
black
ruff
mypy
# requirements/prod.txt
-r base.txt
gunicorn>=21.0
sentry-sdk
# En desarrollo
pip install -r requirements/dev.txt
# En producción
pip install -r requirements/prod.txt
.gitignore y flujo completo de un proyecto
La regla de oro: commitea requirements.txt, nunca .venv/. El directorio .venv contiene binarios compilados para tu sistema operativo y arquitectura, y rutas absolutas de tu máquina. En otro sistema no funcionará. Es pesado (puede ser cientos de MB). Y es completamente innecesario tenerlo en git: cualquiera puede recrearlo en segundos.
## .gitignore mínimo para proyectos Python
# Entorno virtual (NUNCA commitear)
.venv/
env/
venv/
ENV/
# Python cache
__pycache__/
*.py[cod]
*$py.class
*.so
# Variables de entorno secretas (NUNCA commitear)
.env
.env.local
*.env
# IDEs
.idea/
.vscode/
*.swp
El fichero completo de gitignore oficial para Python está en github.com/github/gitignore.
Flujo completo de proyecto nuevo
# ── 1. Crear proyecto ──────────────────────────────────────────
mkdir mi_proyecto && cd mi_proyecto
git init
echo ".venv/" >> .gitignore
echo "__pycache__/" >> .gitignore
# ── 2. Crear y activar entorno ────────────────────────────────
python -m venv .venv
source .venv/bin/activate # (.venv) $
# ── 3. Instalar dependencias ──────────────────────────────────
pip install requests flask pandas
# ── 4. Desarrollar ────────────────────────────────────────────
# ... escribir código ...
# ── 5. Guardar dependencias ───────────────────────────────────
pip freeze > requirements.txt
git add requirements.txt .gitignore
git commit -m "setup: entorno Python con dependencias"
# ── Al clonar en otra máquina ─────────────────────────────────
git clone
cd mi_proyecto
python -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt # entorno idéntico ✓
Herramientas modernas: uv, Poetry y pipx
pip + venv es el stack estándar y funciona perfectamente para la mayoría de proyectos. Pero existe un ecosistema de herramientas que mejoran la experiencia, especialmente para proyectos grandes o equipos.
uv — el reemplazo ultrarrápido
uv es una herramienta escrita en Rust que reemplaza a pip y venv con una API compatible pero 10-100x más rápida. Si trabajas con proyectos con muchas dependencias, la diferencia es significativa:
pip install uv # instalar uv
# Comandos equivalentes a pip + venv
uv venv .venv # crear entorno (igual que python -m venv .venv)
uv pip install requests # instalar paquete (mucho más rápido)
uv pip install -r requirements.txt
uv pip freeze > requirements.txt
Poetry — gestión de dependencias avanzada
Poetry unifica en una sola herramienta la gestión del entorno virtual, las dependencias y la publicación de paquetes. Usa pyproject.toml (el estándar moderno) y genera un poetry.lock que garantiza reproducibilidad exacta:
# Instalar Poetry
curl -sSL https://install.python-poetry.org | python3 -
# Comandos básicos
poetry new mi_proyecto # crear proyecto nuevo con estructura
poetry add requests # añadir dependencia (actualiza pyproject.toml)
poetry add pytest --dev # dependencia de desarrollo
poetry install # instalar todo desde poetry.lock
poetry shell # activar el entorno virtual
poetry run python main.py # ejecutar sin activar el entorno
pipx — herramientas CLI aisladas
pipx instala aplicaciones de línea de comandos Python en entornos virtuales propios, separados entre sí. Es la solución correcta para herramientas globales como black, ruff o httpie:
pip install pipx
pipx install black # formateador de código
pipx install ruff # linter ultrarrápido
pipx install httpie # cliente HTTP para terminal
pipx install cookiecutter # generador de proyectos
pipx list # ver herramientas instaladas
pipx upgrade black # actualizar una herramienta
❓ Preguntas frecuentes
❓ Preguntas frecuentes sobre pip y entornos virtuales en Python
Las dudas más comunes respondidas de forma clara y directa.
💬 Foro de discusión
¿Tienes dudas sobre pip y entornos virtuales en Python? Comparte tu pregunta con la comunidad.
Todavía no hay mensajes. ¡Sé el primero en participar!