Parlavamo poco tempo fa dei consigli per i neofiti della programmazione in merito a quale linguaggio iniziare a studiare per imparare, citando fonti autorevoli che indicavano Python come il miglior candidato possibile.

Tra le tante peculiarità di Python che ne fanno un linguaggio di punta non si finirà mai abbastanza di valorizzare quella dei Virtual Environment: veri e propri ambienti isolati (nella pratica cartelle che contengono file e sottocartelle) all’interno dei quali è possibile effettuare l’installazione di specifiche versioni di software (Python based, ovviamente).

All’interno dello stesso sistema è quindi possibile avere diverse combinazioni di versioni e librerie che coesistono proprio perché contenute in forma isolata nei Virtual Environment, che possono essere attivati o disattivati all’occorrenza.

Quando un Virtual Environment viene creato (mediante python3 -m venv <nome della directory>) ed attivato (mediante source <nome della directory>/bin/activate) tipicamente per installarvi software e librerie si utilizza il comando pip, il package manager Python (Preferred Installer Program) che si preoccupa di gestire il parco software per quell’ambiente.

Il comando pip esiste a livello di sistema, e quindi può installare direttamente nel sistema principale i software e le librerie, trattando quindi l’intero host come un Virtual Environment. Questa pratica non è comunque molto consigliata, poiché prodiga di di situazioni di incoerenza, pensate se un software installato mediante pip va a toccare file installati da un pacchetto nel sistema (deb o rpm che sia)… Insomma, vista l’ampia popolarità di Python, gli utenti possono facilmente violare i pacchetti di distribuzione critici.

Del potenziale problema ne sono al corrente tutti, tanto che come riporta Linux Uprising, le prossime distribuzioni di Debian (Debian 12 Bookworm) e Ubuntu (Ubuntu 23.04 Lunar Lobster) non consentiranno più l’utilizzo di pip al di fuori dei Virtual Environment.

Chiaramente esistono metodi alternativi per aggirare il problema, descritti ampiamente nell’articolo, ma è più che presumibile che la scelta si rifletterà molto presto anche sulle altre distribuzioni (per Fedora 38 c’è già una proposta identica).

Il “blocco”, se così lo vogliamo chiamare, consiste nell’adozione di PEP668 (PEP = Python Enhancement Proposal), che propone di segnare i Python base environments come “externally managed“, non consentendo installazioni “dirette” nell’host mediante pip, né a livello di root, né a livello utente.

Sulla carta è certamente una mossa che favorirà la coerenza nelle installazioni, con una logica inattaccabile, ma è più che probabile come qualcuno potrà trovarsi spiazzato, tanto da chiedersi “ah, perché, non si poteva?”

Raoul Scarazzini

Da sempre appassionato del mondo open-source e di Linux nel 2009 ho fondato il portale Mia Mamma Usa Linux! per condividere articoli, notizie ed in generale tutto quello che riguarda il mondo del pinguino, con particolare attenzione alle tematiche di interoperabilità, HA e cloud.
E, sì, mia mamma usa Linux dal 2009.