por Para empezar a programar con Python en Linux necesitamos comprobar qué intérprete tenemos y preparar un lugar donde instalar las dependencias del proyecto. No hace falta sustituir el Python del sistema por la última versión que encontremos.
Muchas distribuciones utilizan Python para sus propias herramientas. Si cambiamos enlaces de /usr/bin o mezclamos paquetes instalados con APT y con pip, podemos crear un problema que no tiene nada que ver con nuestro programa.
Vamos a utilizar Python 3, crear un entorno virtual y comprobar desde qué intérprete ejecutamos cada orden. Así podremos trabajar en un proyecto sin convertir sus dependencias en una modificación de todo el ordenador.
Comprobar qué Python tenemos
Abrimos la terminal y ejecutamos:
python3 --version
command -v python3
La primera orden muestra la versión. La segunda indica qué ejecutable encuentra la shell. Es útil si hemos instalado más de una distribución de Python o si una aplicación incluye su propio intérprete.
No daría por hecho que python y python3 son lo mismo. El nombre sin número puede no existir o corresponder a una configuración diferente. Para esta guía utilizaremos python3 y, después, la ruta explícita del entorno virtual.
Tampoco necesitamos Python 2 para empezar un proyecto nuevo. Si mantenemos una aplicación antigua que todavía lo exige, ése es otro trabajo de compatibilidad y migración, no un motivo para cambiar el intérprete de todos los programas.
Instalar los paquetes de la distribución
En Ubuntu y Linux Mint podemos preparar las herramientas básicas con:
sudo apt update
sudo apt install python3 python3-venv python3-pip
La distribución elige la versión que mantiene para su sistema. No fijamos en el comando Python 3.7 o 3.6 porque una receta antigua los utilizase. Si un proyecto requiere una versión concreta, tendremos que preparar esa versión por separado.
Después volvemos a comprobar python3 --version. Instalar Python 3 no obliga a que el comando python cambie automáticamente ni requiere añadir una entrada a update-alternatives.
Ejemplo de varios intérpretes disponibles en una instalación antigua. Podemos elegir el de un proyecto sin sustituir el del sistema.
En Fedora u otra distribución utilizaríamos sus paquetes equivalentes. No copiaríamos una orden de APT en un sistema que gestiona el software con otro gestor.
Crear una carpeta y su entorno virtual
Elegimos una carpeta nueva para una prueba sencilla:
mkdir proyecto-python
cd proyecto-python
python3 -m venv .venv
Si ya existe proyecto-python, revisamos su contenido antes de usarla. .venv es el directorio que contendrá el intérprete del entorno y sus paquetes. Nuestro código se guarda fuera de ese directorio, dentro de la carpeta del proyecto.
La documentación de venv explica cómo se construye a partir de un Python instalado. No descarga por sí solo otra versión del lenguaje. Si ejecutamos la creación con Python 3.12, el entorno se basa en ese intérprete.
Comprobamos que está separado del Python base:
.venv/bin/python -c "import sys; print(sys.prefix != sys.base_prefix)"
.venv/bin/python -m pip --version
La primera comprobación debe mostrar True. La ruta que aparece en la segunda debe corresponder al entorno que acabamos de crear, no a otro proyecto.
Ejecutar Python sin activar el entorno
Podemos utilizar directamente su ejecutable:
.venv/bin/python -c "print('Python preparado')"
Si guardamos un archivo hola.py con nuestro editor:
print('Hola desde Python')
Lo ejecutamos con:
.venv/bin/python hola.py
Esta forma hace explícito qué intérprete estamos usando. Resulta útil en tareas de un editor o en automatizaciones donde no tenemos una terminal interactiva abierta.
No debemos guardar hola.py dentro de .venv. El entorno es una herramienta que podemos recrear, no el lugar donde conservar el trabajo.
Activarlo cuando trabajamos en la terminal
En Bash podemos activar el entorno con:
source .venv/bin/activate
python --version
python -m pip --version
La activación modifica la búsqueda de comandos de esa shell para utilizar el entorno. No sustituye el Python del sistema ni cambia todas las aplicaciones abiertas.
Para salir de ese estado:
deactivate
Si utilizamos otra shell, seguimos su método de activación. La guía de entornos virtuales de Python recoge el funcionamiento básico. Podemos evitar esa diferencia utilizando siempre .venv/bin/python.
Instalar una dependencia en el lugar correcto
Cuando un proyecto necesita un paquete, lo instalamos mediante el pip de su intérprete. Si ya dispone de un archivo de requisitos:
.venv/bin/python -m pip install -r requirements.txt
Leemos ese archivo y su procedencia antes de instalarlo. Una dependencia puede ejecutar código durante su instalación o cuando la utilicemos. Un entorno virtual separa paquetes, pero no es una máquina aislada para ejecutar software desconocido.
También podemos comprobar lo instalado:
.venv/bin/python -m pip list
.venv/bin/python -m pip freeze
La guía de instalación de PyPA desarrolla ese flujo. Utilizar python -m pip ayuda a mantener unidos el intérprete y el instalador, en lugar de confiar en un pip que quizá pertenece a otra instalación.
En un proyecto existente seguiríamos su gestor de dependencias y sus instrucciones. No añadimos un segundo método de instalación sólo porque acabamos de aprender éste.
Entender el error externally-managed-environment
En algunas distribuciones, pip rechaza instalar paquetes directamente en el Python gestionado por el sistema. La especificación de entornos gestionados externamente describe ese mecanismo para evitar conflictos con el gestor de la distribución.
Si aparece externally-managed-environment, no empezaría borrando el marcador ni usando sudo pip. Comprobamos qué intérprete hemos llamado y si estamos instalando dentro de .venv.
Tampoco utilizaría --break-system-packages como solución general de un tutorial de iniciación. Si el objetivo es añadir una biblioteca al proyecto, el entorno virtual resuelve esa necesidad sin modificar los paquetes del sistema.
Si el problema es que falta el módulo para crear el entorno, revisamos python3-venv o el paquete correspondiente a la versión elegida. Cambiar arbitrariamente el enlace de python no instala ese módulo.
Conservar el proyecto sin copiar el entorno entero
En Git guardamos el código y los archivos que describen las dependencias. Habitualmente excluimos .venv, porque contiene rutas y elementos de la instalación local.
Al cambiar de ordenador, recreamos el entorno con la versión de Python adecuada y reinstalamos las dependencias del proyecto. Copiar la carpeta .venv no es una forma fiable de trasladarlo entre sistemas.
Si instalamos otra versión de Python para un trabajo concreto, creamos otro entorno con ese ejecutable y comprobamos las rutas. No reorganizamos el Python que necesita la distribución para hacer coincidir todos los comandos.
Con esa separación resulta más fácil entender un error: sabemos qué intérprete ejecuta el código y qué paquetes le pertenecen. Es una base más útil que tener muchas versiones instaladas sin saber cuál utiliza cada programa.
