Usare pip fuori da un Virtual Environment Python non sarà più possibile nelle prossime Debian/Ubuntu (e forse Fedora)
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 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.
Se vuoi sostenerci, puoi farlo acquistando qualsiasi cosa dai diversi link di affiliazione che abbiamo nel nostro sito o partendo da qui oppure alcune di queste distribuzioni GNU/Linux che sono disponibili sul nostro negozio online, quelle mancanti possono essere comunque richieste, e su cui trovi anche PC, NAS e il ns ServerOne. Se ti senti generoso, puoi anche donarmi solo 1€ o più se vuoi con PayPal e aiutarmi a continuare a pubblicare più contenuti come questo. Grazie!
Hai dubbi o problemi? Ti aiutiamo noi!
Se vuoi rimanere sempre aggiornato, iscriviti al nostro canale Telegram.Se vuoi ricevere supporto per qualsiasi dubbio o problema, iscriviti alla nostra community Facebook o gruppo Telegram.
Cosa ne pensi? Fateci sapere i vostri pensieri nei commenti qui sotto.
Ti piace quello che leggi? Per favore condividilo con gli altri.
