Installare e usare Python su Windows (parte 3/10).

Attenzione!

Queste guide non sono più aggiornate, e in alcuni punti sono proprio superate.
Il mio libro Python in Windows tratta questi temi, e molto altro, in modo molto più completo e aggiornato. 

Virtual environment.

Quanto abbiamo visto fino a questo punto è sufficiente per iniziare a programmare con Python, almeno fino a un punto ben preciso: la prima volta che vi trovate a dover installare un pacchetto esterno alla libreria standard.
Quando installate Python, installate anche la sua libreria standard: una grande famiglia di moduli pensati per risolvere ogni genere di problemi comuni, dalla matematica al logging, dai database al markup parsing, dalla concurrency alle regular expression, e molto altro. Tutto ciò che sta nella libreria standard è utilizzabile: basta importare quello che vi serve nel vostro script. Nelle diverse incarnazioni del nostro script test.py, ci è già capitato di importare i moduli sys, time, winsound.
Potete fare molta strada solo con la libreria standard. Se state imparando a programmare in Python, è possibile (e perfino consigliabile) limitarsi alla libreria standard per molti mesi, prima di iniziare a esplorare altro. Ma prima o poi vi troverete nella necessità di installare anche delle librerie esterne, per coprire nuovi scenari, o per fare le stesse cose in modo diverso e migliore.
Un chiarimento terminologico, prima di proseguire. Qui non stiamo parlando di installare “un programma”, nel senso di un software compiuto destinato all’utente finale. Un “programma” scritto in Python si installa come un qualsiasi altro: per esempio, Calibre è un programma per la gestione di e-book, ed è scritto in Python. Se vi piace, potete scaricarlo e installarlo. Ciò che scaricate è il programma Calibre pacchettizzato e distribuito per l’utente finale. Noi però qui stiamo parlando di software scritto in Python e distribuito come una “libreria”, o magari un “framework”: si tratta di codice che non è destinato agli utenti finali, ma ai programmatori per aiutarli a scrivere altro codice. I moduli della libreria standard sono un esempio: sys, time, winsound etc. non sono programmi per l’utente, ma componenti da importare nei vostri programmi.
Installare librerie esterne in Python è veramente molto facile, al punto che il problema è che… ne installerete troppe. Nel corso del tempo è facile riempire la propria installazione Python con un mucchio di librerie esterne scaricate e installate per prova, per esigenze temporanee, per progetti poi chiusi o accantonati, etc. Inoltre, lavorando in certi ambiti (un esempio tipico: le applicazioni per il web) è facile trovarsi a dover installare decine di pacchetti esterni. La manutenzione di tutto questo può diventare un incubo.
Per questo bisogna imparare a far bene le cose fin dall’inizio. Prima di imparare a installare pacchetti esterni, dovete imparare a creare e gestire i virtual environment.

Che cosa è un virtual environment.

Un virtual environment (d’ora in poi “venv” per brevità) è una installazione isolata di Python, creata a partire dal Python “globale”, di sistema che avete già installato. In concreto, è una directory separata in cui si copiano i file necessari all’esecuzione di Python e la sua libreria standard: successivamente è possibile installare i pacchetti esterni direttamente nel venv, invece che nel Python “principale”.
I vantaggi dei venv sono molteplici: permettono di non inquinare l’installazione di Python con dozzine di pacchetti che magari servono solo a un progetto particolare; permettono soprattutto di tenere sotto stretto controllo i pacchetti che servono all’esecuzione di un determinato progetto (le sue “dependencies”, come si chiamano). Quando un venv non serve più, semplicemente lo si cancella; se sbagliate a installare qualcosa, o non siete sicuri di aver fatto la cosa giusta, potete buttare via il venv e ricominciare daccapo; etc.
La strategia abituale è di creare un venv separato per ciascun nuovo progetto “importante”. Potete naturalmente creare un venv di servizio generico da usare per gli script veloci, i progettini, gli esperimenti. Ma non appena un progetto cresce, e ha bisogno di “dependencies” esterne ben precise, è fondamentale creare un venv solo per lui.

Dove mettere i virtual environment.

Concretamente, i venv sono delle directory con dentro una copia di Python e della libreria standard (più precisamente: un puntatore ai file della libreria standard, per evitare di copiarli fisicamente. Ma questo è un dettaglio). Ci finiscono dentro poi tutti i pacchetti esterni che installerete via via. Potete creare un venv dove volete. Una soluzione abbastanza comune su Windows (copiando le convenzioni di Linux) è installarli in una apposita directory envs nella propria cartella personale (ovvero in %USERPROFILE%/envs).
Tenete conto che, lavorando, finirete per creare parecchi venv, e che ciascuno occupa spazio e comprende centinaia di file: se la vostra cartella personale è soggetta a backup periodico e non potete escludere %USERPROFILE%/envs dai backup (per esempio, lavorate su una macchina aziendale ed è complicato spiegarlo all’amministratore), può essere fastidioso.
Talvolta è preferibile una soluzione differente. Nel seguito di questi appunti useremo la directory D:/envs come base per i nostri venv. Questa potrebbe non essere una buona politica se la macchina è usata da più utenti, visto che in genere il drive D: viene lasciato come “terra di tutti”. Ma è una path corta da scrivere nella shell, e in ogni caso se per voi non va bene potete adottare la soluzione che più vi fa comodo. Se volete seguire questi appunti passo-passo, create quindi una directory vuota D:/envs prima di procedere.

Creare e usare un virtual environment di Python 3.7.

Le versioni di Python più recenti (dalla 3.3 in poi) hanno un modulo venv nella libreria standard che permette appunto di creare i venv. Il procedimento è molto semplice: portatevi con la shell nella directory D:/envs, e invocate il modulo venv per creare il nuovo venv:

> cd d:/envs
D:\envs > py -3 -m venv test

Questo richiede qualche spiegazione aggiuntiva. Notate che abbiamo specificato l’opzione -3 del launcher py per indicare che vogliamo eseguire Python 3. L’opzione -m vuol dire che non ci interessa invocare la shell di Python, ma vogliamo invece che Python esegua un modulo in particolare: in questo caso, il modulo venv con l’argomento ulteriore test che è semplicemente il nome che vogliamo dare al venv che stiamo creando.
Con questo abbiamo creato un nuovo venv di nome test. Concretamente, questo significa che adesso esiste una directory d:/envs/test con dentro i file necessari a eseguire Python 3.7 e la sua libreria standard (controllate pure!).
Per “usare” un venv bisogna prima “attivarlo”. Per questo scopo esiste un batch script activate.bat che viene sempre copiato nel processo di creazione del venv: potete usarlo in questo modo:

> d:/envs/test/scripts/activate
(test) >

Da una directory di lavoro qualsiasi, in questo modo avete attivato il venv. Notate che adesso il prompt indica la stessa directory di prima, ma preceduta dal nome del venv (test nel nostro caso): questo vuol dire che adesso state lavorando “dentro” il venv. Da un punto di vista concreto, vuol dire semplicemente che l’indirizzo dell’interprete Python del venv è stato aggiunto in testa alla path di sistema (potete controllare con un semplice echo %PATH%, se volete).
E questo a sua volta vuol dire che adesso tutte le invocazioni a py oppure python saranno indirizzate al Python del venv, invece che al Python di sistema. Potete verificarlo con il metodo già noto (questa volta lavoriamo direttamente dalla shell di Python, per cambiare un po’):

(test) > py
Python 3.7.0 ([etc]) on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> print(sys.executable)
d:\envs\test\Scripts\python.exe
>>> exit()
(test) > python
Python 3.7.0 ([etc]) on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> print(sys.executable)
d:\envs\test\Scripts\python.exe
>>> exit()
(test) >

Come vedete, finché siete dentro al venv, le chiamate a py oppure python vengono dirottate sull’eseguibile Python che si trova dentro il venv. Notate però che se voi invocate il launcher specificando una versione particolare (per esempio py -2 oppure py -3), allora il launcher avvierà il Python di sistema, anche se siete dentro al venv.
Lo stesso capita se volete eseguire uno script: se invocate py test.py (oppure python test.py) da dentro un venv, lo script viene eseguito dall’interprete del venv.
Per uscire da un venv, basta invocare deactivate dalla shell (concretamente, esiste un bash script deactivate.bat che rimette a posto la path di sistema):

(test) > deactivate
> 

Una volta usciti dal venv, per cancellarlo completamente basta eliminare fisicamente la directory che lo contiene.

Creare un virtual environment di Python 2.7.

Python 2 non ha il modulo venv nella sua libreria standard: quindi occorre installarlo come pacchetto esterno. Per questo scopo esiste uno strumento apposito che si chiama Pip. Impareremo a capire come funziona tra non molto: per il momento, fidatevi e semplicemente

> pip2 install virtualenv

Questo scaricherà e installerà il pacchetto virtualenv nel votro Python 2 di sistema. Non avevamo detto che non bisogna mai installare pacchetti esterni nel Python “globale”, ma solo dentro ai venv? Sì ma questa è un’eccezione: d’altra parte, se non installiamo globalmente almeno il pacchetto necessario per creare i venv, come possiamo installare tutto il resto dentro ai venv?
Una nota: nella stragrande maggioranza dei casi, avrete una sola versione di Python 2 installata (tipicamente, Python 2.7). Se per qualche ragione particolare invece avete installato due versioni di Python 2 (per esempio, Python 2.7 e Python 2.6), allora pip2 non basta a identificarle in modo univoco. In questo caso, usate invece pip2.7 per installare virtualenv in Python 2.7, e poi pip2.6 per installarlo in Python 2.6.
Il pacchetto virtualenv, tra le altre cose, installa uno script virtualenv.exe nella directory Scripts del vostro Python 2 (nel nostro caso, quindi, C:/Python27/Scripts/virtualenv.exe: potete controllare). Per creare un venv di Python 2, quindi, vi basterà:

> cd d:/envs
D:\envs > virtualenv test_py2

Questo crea un venv di Python 2 di nome test_py2 in d:/envs: fisicamente, una directory d:/envs/test_py2 con l’interprete di Python 2 e tutto il resto.
Ancora una nota (che prosegue quella di prima): se avete una sola installazione di Python 2, come in genere avviene, allora avete anche un solo virtualenv.exe che Windows può trovare nella path di sistema (ricordiamo infatti che Python 3 non ha nessun virtualenv, ma un modulo venv). Se però avete due o più versioni di Python 2 installate (2.6 e 2.7 per esempio), allora dovete per forza specificare con quale virtualenv volete creare il vostro venv. Per esempio, per Python 2.7 sarebbe D:\envs > c:/python27/scripts/virtualenv test_py2.
Una volta creato il venv, le operazioni successive sono le stesse che abbiamo visto per i venv di Python 3. Per attivarlo basterà:

> d:/envs/test_py2/scripts/activate
(test_py2) >

Per disattivarlo:

(test_py2) > deactivate
> 

Per rimuoverlo, basta cancellare la directory in cui risiede.

Eseguire script nei virtual environment.

Potete avviare la shell Python o eseguire uno script quando siete nel contesto di un venv. Potete usare il launcher py o l’invocazione diretta dell’interprete python.
Se invocate py all’interno di un venv, senza specificare un numero di versione, il launcher vi restituisce l’interprete Python che trova nel venv. Se invece specificate una versione (per esempio, py -2), allora il launcher sceglie sempre l’interprete “globale” di sistema (anche se il Python del venv è lo stesso!). Per esempio, se siete all’interno di un venv di Python 3, allora:

• py test.py esegue il modulo con il Python 3 del venv;
• py -3 test.py lo esegue con il Python 3 di sistema;
• py -2 test.py, naturalmente, lo esegue con il Python 2 di sistema.

Se invece eseguite il modulo con python test.py, allora sicuramente avrete l’interprete del venv, perché è il primo che Windows trova nella path di sistema.
Potete testare voi stessi tutte le varianti possibili, creando venv di Python 3 e Python 2, e poi avviando il nostro test.py dentro e fuori dal venv, in vari modi. Vi conviene tornare alla prima versione del modulo (quella che aveva semplicemente le righe import sys; print(sys.executable)).
Una nota: a questo punto dovrebbe essere ovvio perché “fare doppio clic” su uno script Python non è il modo giusto per eseguirlo. L’utilizzo dei venv costringe a usare la shell: facendo doppio clic, lo script viene sempre interpretato dal Python di sistema. In teoria potreste ri-associare manualmente le estensioni .py e .pyw all’interprete Python del venv: in pratica però costruirete e distruggerete venv di continuo, e passerete sempre da un venv all’altro… cambiare le associazioni ogni volta sarebbe assurdo.

Riassunto: come funziona py (e python), con e senza i venv.

Aggiorniamo la nostra tabella dei diversi modi in cui si usa il launcher.

• py non qualificato (py script.py):
  • fuori da un venv: avvia lo script con la versione più recente di Python (o quella impostata da PY_PYTHON);
  • dentro il venv: avvia lo script con la versione del venv.
• py qualificato (es. py -3 script.py):
  • avvia lo script sempre con la versione specifica del Python di sistema, anche se siete dentro un venv.
• python (python script.py): avvia sempre lo script con il primo interprete che Windows trova nella path, e pertanto:
  • fuori da un venv, con il Python “di default”
  • dentro un venv, sempre con il Python del venv.