Installare Python 3.x o 2.7 su Debian 11 Bullseye

Debian 11 Bullseye: Python 3 è il default, Python 2.7 no

Su Debian 11 Bullseye la scelta pratica è netta: Python 3 è il percorso supportato, mentre Python 2.7 non va considerato parte del sistema base. Se devi installare Python 3.x, in genere lo hai già disponibile dal repository ufficiale; se devi far girare un software vecchio che pretende Python 2.7, la strada corretta è isolarlo e ridurre l’impatto sul resto della macchina.

Il punto non è “trovare un modo per forzarlo”, ma decidere quanto rischio vuoi introdurre. Su un host Debian 11 in produzione, sovrascrivere interpreter di sistema, aggiungere repository casuali o compilare in modo approssimativo sono scorciatoie che si pagano dopo: dipendenze rotte, upgrade più difficili, pacchetti che confliggono e, nel caso peggiore, servizi che partono con la versione sbagliata di Python.

Qui sotto trovi una procedura pulita per: verificare cosa è già presente, installare Python 3.x nel modo corretto, gestire un ambiente virtuale, e trattare Python 2.7 solo se hai una dipendenza legacy che non puoi migrare subito.

Verifica prima di toccare il sistema

Prima di installare qualsiasi cosa, controlla lo stato reale del sistema. Su Bullseye spesso Python 3 è già presente, ma non dare per scontato che il binario, il modulo python3-venv e gli strumenti di build siano tutti installati.

La verifica minima è questa:

python3 --version
which python3
dpkg -l | grep -E '^ii\s+python3|^ii\s+python3-venv|^ii\s+python3-pip'
apt-cache policy python3 python3-venv python3-pip

Se python3 --version risponde con una versione 3.9.x, sei allineato al ramo standard di Debian 11. Se invece il comando manca o punta a qualcosa di inatteso, c’è quasi sempre un problema di PATH, di installazione incompleta o di ambiente minimalista.

Per capire se stai usando un sistema alterato, guarda anche il default dei pacchetti e l’origine:

apt policy python3
apt policy python3.9
ls -l /usr/bin/python3

Se il link simbolico in /usr/bin/python3 è quello atteso dal pacchetto Debian, non c’è nessun motivo per sostituirlo con un wrapper artigianale. Se invece trovi un binario installato a mano in /usr/local/bin che precede il pacchetto di sistema, hai già un possibile punto di rottura per script e servizi.

Installare Python 3.x su Debian 11 nel modo corretto

Se il sistema è pulito, l’installazione standard è semplice e reversibile. Su Bullseye il ramo supportato è Python 3.9, quindi in genere basta installare il pacchetto base e gli strumenti accessori che ti servono davvero.

sudo apt update
sudo apt install python3 python3-venv python3-pip

Questa è la combinazione minima ragionevole per la maggior parte dei casi: interpreter, ambiente virtuale e pip. Se devi compilare moduli con estensioni native, aggiungi gli header e i tool di build:

sudo apt install build-essential python3-dev

Qui il criterio è semplice: installa solo ciò che serve al tuo caso d’uso. python3-dev non è obbligatorio per usare Python, ma serve quando un package compila componenti C o quando devi installare moduli che richiedono header di sviluppo.

Dopo l’installazione, verifica che il pacchetto sia quello atteso e che il binario risponda correttamente:

python3 --version
python3 -c 'import sys; print(sys.executable); print(sys.version)'
apt-cache policy python3

Se vuoi sapere esattamente quali file ha installato il pacchetto, usa dpkg -L:

dpkg -L python3 | head -n 20

Questo è utile quando devi documentare un server o capire da dove arriva un binario in un ambiente dove altri hanno già fatto modifiche manuali.

Usare un virtual environment invece di sporcare il sistema

Per applicazioni, script e servizi custom, il comportamento più sano è quasi sempre lo stesso: usa un virtual environment. Eviti conflitti tra versioni di librerie, tieni separati i requisiti del progetto e semplifichi il rollback.

La sequenza minima è questa:

mkdir -p /opt/app
cd /opt/app
python3 -m venv .venv
. .venv/bin/activate
python -m pip install --upgrade pip

Se il comando python3 -m venv fallisce con un messaggio sul modulo mancante, in genere significa che python3-venv non è installato. In quel caso la correzione è banale e non richiede workaround: installi il pacchetto mancante e ripeti il comando.

Quando devi installare dipendenze per il progetto, fallo dentro l’ambiente virtuale:

python -m pip install -r requirements.txt

Se il progetto è esposto come servizio systemd, punta direttamente al binario del venv. È una scelta più robusta rispetto a chiamare un python generico del sistema, che potrebbe cambiare comportamento dopo un aggiornamento o dopo un intervento manuale.

[Service]
WorkingDirectory=/opt/app
ExecStart=/opt/app/.venv/bin/python /opt/app/app.py
Restart=on-failure

Se usi systemd, dopo ogni modifica ricordati il reload:

sudo systemctl daemon-reload
sudo systemctl restart nome-servizio
sudo systemctl status nome-servizio --no-pager

Python 2.7 su Debian 11: quando serve davvero e come non farsi male

Qui serve essere netti: Python 2.7 non è la scelta normale su Debian 11. Se un software lo richiede ancora, il problema non è “installarlo”, ma isolare il legacy e avere un piano di uscita. Il motivo è banale: Python 2 è fuori supporto da tempo e trascina con sé librerie vecchie, toolchain fragili e una superficie di manutenzione più alta.

La prima domanda da farsi non è “come lo installo?”, ma “posso evitarlo?”. Se la risposta è sì, migra. Se la risposta è no, allora scegli uno di questi due approcci: contenitore oppure compilazione isolata in una directory dedicata. Evita di sostituire /usr/bin/python o di creare symlink globali che impattano script di sistema.

Approccio consigliato: contenitore o host separato

Se devi far girare un’applicazione legacy, la soluzione più pulita è containerizzare l’ambiente con una base compatibile, oppure spostarlo su una VM dedicata. In questo modo non forzi il sistema Debian 11 a ospitare un runtime vecchio e riduci il rischio di conflitti con pacchetti moderni.

Questo approccio è preferibile anche quando devi mantenere più progetti diversi sullo stesso host. Un runtime vecchio e uno nuovo, nello stesso filesystem di sistema, sono una fonte classica di problemi operativi.

Compilare Python 2.7 in modo isolato

Se proprio devi costruire Python 2.7 sul server, fallo in una directory separata e senza sovrascrivere il sistema. Il principio è: installazione locale, prefisso esplicito, nessun binario globale ambiguo.

sudo apt update
sudo apt install build-essential wget libssl-dev zlib1g-dev \
  libreadline-dev libsqlite3-dev libbz2-dev libffi-dev tk-dev

cd /usr/src
sudo wget https://www.python.org/ftp/python/2.7.18/Python-2.7.18.tgz
sudo tar -xzf Python-2.7.18.tgz
cd Python-2.7.18
sudo ./configure --prefix=/opt/python2.7 --enable-shared
sudo make -j"$(nproc)"
sudo make altinstall

Il punto importante è make altinstall: evita di registrare il binario come python di sistema. Dopo l’installazione, il comando atteso sarà qualcosa come /opt/python2.7/bin/python2.7.

Verifica subito l’esito e l’eventuale link dinamico:

/opt/python2.7/bin/python2.7 --version
ldd /opt/python2.7/bin/python2.7 | grep -E 'ssl|zlib|readline|sqlite'

Se il binario non parte per librerie mancanti, il fix va fatto in modo puntuale, non con un upgrade cieco del sistema. Prima identifichi la libreria assente, poi installi il pacchetto corrispondente o correggi il LD_LIBRARY_PATH solo se sai esattamente cosa stai facendo.

pip, moduli e dipendenze: cosa cambia tra Python 3 e 2.7

Con Python 3 su Debian 11 il flusso è lineare: python3-pip, virtualenv e requisiti del progetto. Con Python 2.7, invece, trovi spesso repository di pacchetti ormai vecchi, nomi diversi e dipendenze che non compilano più senza patch.

Per Python 3, la regola è semplice:

python3 -m pip install --upgrade pip setuptools wheel
python3 -m pip install requests flask gunicorn

Per Python 2.7, se sei costretto a usarlo, lavora in un ambiente isolato e usa versioni compatibili dei pacchetti. Spesso serve anche un pip vecchio o una procedura legacy dedicata; il punto però resta lo stesso: non mischiare i due mondi nello stesso interpreter di sistema.

Un errore comune è installare moduli con pip senza essere sicuri dell’interprete. Il controllo corretto è sempre questo:

python3 -m pip --version
python3 -m pip show nomepacchetto

Così eviti di installare librerie nel Python sbagliato, cosa che succede spesso quando esistono più runtime sullo stesso host.

Errori tipici e lettura rapida dei sintomi

Se il comando python3 manca, il problema è quasi sempre un’installazione minima o un PATH alterato. Se python3 -m venv non funziona, manca il pacchetto python3-venv. Se un’app parte con una versione sbagliata, il problema è nel servizio, nel wrapper o nel symlink, non nel pacchetto Debian.

Per isolare rapidamente il guasto, questi controlli coprono la maggior parte dei casi:

command -v python3
readlink -f "$(command -v python3)"
python3 -c 'import sys; print(sys.executable)'
env | grep -E '^PYTHON|^PATH='

Se il binario risolve in /usr/local/bin invece che in /usr/bin, hai probabilmente una installazione manuale che precede quella di sistema. Non è per forza sbagliata, ma va trattata come eccezione documentata, non come default invisibile.

Un altro sintomo classico è il modulo compilato che fallisce con errori di header o librerie. In quel caso non serve reinstallare Python da capo: controlla prima i pacchetti di sviluppo, il log di build e la versione del compilatore.

sudo apt install build-essential python3-dev
python3 -m pip install --no-cache-dir nomepacchetto

Rollback sensato: come tornare indietro senza lasciare residui

Ogni volta che tocchi interpreter, moduli o percorsi di sistema, devi sapere come tornare indietro. Se hai usato i pacchetti Debian, il rollback è semplice e pulito. Se hai compilato in /opt/python2.7, basta rimuovere quella directory e gli eventuali servizi che la referenziano.

Per i pacchetti installati via APT, verifica cosa è stato aggiunto e rimuovi solo il necessario:

dpkg -l | grep -E '^ii\s+python3-venv|^ii\s+python3-pip|^ii\s+python3-dev'
sudo apt purge python3-pip python3-venv python3-dev
sudo apt autoremove

Per una build manuale di Python 2.7, il rollback è ancora più chiaro se hai rispettato il prefisso dedicato:

sudo rm -rf /opt/python2.7

Prima di eseguire una rimozione, controlla sempre quali servizi o script puntano a quel percorso. Una verifica rapida con grep sui file unit systemd e sugli script di deploy ti evita di cancellare un runtime ancora referenziato.

grep -R "/opt/python2.7\|python3\|python2.7" /etc/systemd /opt 2>/dev/null

In sintesi operativa: su Debian 11 installa e usa Python 3 con i pacchetti ufficiali, crea virtual environment per ogni applicazione, e tratta Python 2.7 come eccezione temporanea da isolare. Il punto non è farlo partire a tutti i costi, ma mantenere il server governabile anche tra sei mesi.

Assunzione: il sistema è Debian 11 Bullseye standard, con accesso root o sudo e necessità di mantenere il minor impatto possibile su servizi già in produzione.