Cuando arrancas cualquier distribución Linux moderna —Ubuntu, Fedora, Debian, lo que sea— Python ya está ahí. No lo instalaste tú. Lo instaló el sistema, y tiene dueño: el sistema operativo.
Eso cambia completamente cómo debes pensar la instalación de Python en Linux, porque no estás partiendo de cero. Estás compartiendo espacio con herramientas que dependen de ese Python para funcionar.
El Python del sistema no es tu Python
Herramientas críticas como apt, dnf, yum o scripts de administración del sistema están escritas en Python y apuntan al intérprete del sistema —normalmente en /usr/bin/python3. Si modificas ese entorno con pip install sin cuidado, puedes romper dependencias que esas herramientas necesitan. No es un escenario teórico: instalar una versión distinta de una librería que usa apt puede dejarte sin gestor de paquetes hasta que lo repares manualmente.
El problema técnico es que pip install sin virtualenv escribe en los directorios de paquetes del sistema (/usr/lib/python3/dist-packages o similar). Esos directorios son territorio del gestor de paquetes de la distro. Cuando apt instala algo que también usa Python, asume que el entorno está en el estado que él mismo dejó. Si tú metiste mano, la consistencia se rompe.
Por eso la regla de oro es: nunca uses pip directamente sobre el Python del sistema.
Cuándo usar cada método de instalación
Tienes varias opciones dependiendo de lo que necesites:
Gestor de paquetes de la distro (apt, dnf): la forma más segura para instalar una versión “oficial” que la distro empaquetó y probó. El problema es que suele ser la versión que la distro decidió incluir, no necesariamente la última.
# En Ubuntu/Debian sudo apt install python3.11 # En Fedora sudo dnf install python3.12
deadsnakes PPA (solo Ubuntu): un repositorio mantenido por la comunidad que ofrece versiones de Python más nuevas o más viejas que las que Ubuntu incluye por defecto. Es la solución pragmática cuando necesitas Python 3.12 en Ubuntu 22.04 sin compilar nada.
sudo add-apt-repository ppa:deadsnakes/ppa sudo apt update sudo apt install python3.12 python3.12-venv python3.12-dev
Fíjate en python3.12-venv y python3.12-dev: sin ellos no puedes crear virtualenvs ni compilar extensiones C. deadsnakes los separa en paquetes distintos.
Compilar desde fuente: máximo control, pero lento y requiere resolver dependencias de compilación. Útil en servidores donde no tienes acceso a PPAs externos o necesitas flags de compilación específicos.
pyenv: la solución más limpia para desarrollo local cuando necesitas múltiples versiones. Lo vemos ahora.
pyenv: múltiples versiones sin tocar el sistema
pyenv descarga, compila e instala versiones de Python completamente dentro de tu directorio home (~/.pyenv). No necesita sudo. No toca /usr/bin. El sistema operativo nunca se entera.
# Instalar pyenv (el instalador oficial hace todo el trabajo) curl https://pyenv.run | bash
Después de instalarlo, necesitas añadir estas líneas a tu ~/.bashrc o ~/.zshrc:
export PYENV_ROOT="$HOME/.pyenv" [[ -d $PYENV_ROOT/bin ]] && export PATH="$PYENV_ROOT/bin:$PATH" eval "$(pyenv init -)"
Recarga el shell (exec "$SHELL") y ya puedes trabajar:
# Ver versiones disponibles pyenv install --list # Instalar una versión específica pyenv install 3.12.3 # Definir la versión global por defecto para tu usuario pyenv global 3.12.3 # Definir una versión solo para el directorio actual del proyecto pyenv local 3.11.9 # crea un archivo .python-version en el directorio
El archivo .python-version que crea pyenv local es lo que hace esto elegante: cada proyecto puede declarar qué versión necesita, y pyenv la activa automáticamente cuando entras al directorio.
# Verificar que estás usando el Python de pyenv, no el del sistema which python3 # → /home/tu_usuario/.pyenv/shims/python3 ✓ bien python3 --version # → Python 3.12.3
Lo que pasa por dentro
El mecanismo de pyenv es simple y brillante: añade ~/.pyenv/shims/ al inicio de tu PATH. Ese directorio contiene ejecutables “fantasma” con el nombre python3, python, pip, etc. Cuando llamas a python3, en realidad llamas al shim de pyenv, que mira si hay un .python-version en el directorio actual, luego en los directorios padre, y finalmente cae en la versión global. Solo entonces ejecuta el intérprete real correspondiente.
El Python del sistema sigue intacto en /usr/bin/python3. apt y sus amigos lo siguen encontrando exactamente donde esperan.
Errores que debes conocer
Error: Instalar paquetes con sudo pip3 install para evitar errores de permisos.
# ❌ Wrong sudo pip3 install requests # ✅ Right python3 -m venv .venv && source .venv/bin/activate pip install requests
sudo pip escribe como root en el Python del sistema. El virtualenv resuelve el problema de permisos sin tocar nada del sistema.
Error: Instalar pyenv pero olvidar python3.xx-dev y los headers de compilación, lo que hace fallar pyenv install.
# ❌ Wrong pyenv install 3.12.3 # → ERROR: The Python ssl extension was not compiled... # ✅ Right sudo apt install build-essential libssl-dev zlib1g-dev \ libbz2-dev libreadline-dev libsqlite3-dev libffi-dev pyenv install 3.12.3
pyenv compila Python desde fuente, y sin esas dependencias del sistema el build falla o produce un intérprete sin módulos esenciales como ssl.
Error: Asumir que pyenv global afecta al usuario root o a otros usuarios del sistema.
# ❌ Wrong # Configuras pyenv global 3.12.3 y esperas que cron o systemd lo usen # ✅ Right # En scripts del sistema, usa la ruta absoluta del intérprete de pyenv /home/tu_usuario/.pyenv/versions/3.12.3/bin/python3 mi_script.py
pyenv opera completamente en el espacio de tu usuario. Cualquier proceso que no herede tu PATH —cronjobs, servicios systemd, sudo— no verá los shims de pyenv.
N° 9