ricpol/Python_Win_Pacchetti.md

## Python_Win_Pacchetti.md

      
    Raw
  

              Python_Win_Pacchetti.md
            
          
    Come installare pacchetti Python in Windows.

NOTA:
Questi appunti sono ormai molto datati e incompleti. Li lascio qui per ragioni storiche e affettive, ma davvero, non prendeli alla lettera e non sorprendetevi se ci sono cose sbagliate.
Il mio libro Python in Windows parla di tutte queste cose, e di molto altro ancora, in modo più aggiornato, completo e corretto. Vi suggerisco almeno di scaricare il capitolo introduttivo gratuito per farvi un'idea degli argomenti trattati.
Questa guida è per i principianti che cercano un po' di chiarezza sull'installazione di pacchetti Python in ambiente Windows: non è detto che risolverà tutti i vostri problemi, ma dovrebbe aiutarvi almeno a coprire i fondamentali.
Pre-requisiti

Questa guida dà per scontato che:

Avete una versione moderna di CPython (ovvero, la versione "normale" di Python implementata in C, quella che potete scaricare dal sito ufficiale per intenderci) installata correttamente su Windows:


qui non descriviamo come installare Python stesso. Non è difficile, ma ci sono comunque alcune sottigliezze da considerare, e probabilmente questo argomento merita una guida a sé stante.
supponiamo che abbiate una sola versione di Python installata. Se avete due o più versioni contemporaneamente installate, quasi tutto quello che trovate in questa guida resta valido. Ma ci sono dettagli che possono complicare la vita.
supponiamo che abbiate installato Python "puro", ovvero la distribuzione CPython che trovate su www.python.org, e non altre distribuzioni come Anaconda, etc. Le varie distribuzioni "non-ufficiali" possono talvolta semplificare la vita, ma anche complicarla parecchio: in ogni caso, non sono oggetto di questa guida.


Avete almeno una conoscenza di base della shell del vostro sistema operativo:


la shell standard di Windows è cmd.exe (la familiare "dos-box" nera, per intenderci). E' almeno necessario che sappiate aprirla, muovervi tra le directory, avere la nozione di "directory corrente". Ovviamente, più ne sapete (creare/eliminare file e directory, etc.), meglio è. Se non sapete proprio nulla, cercate in rete (per esempio questa guida).
cmd.exe è molto limitata e ha un sacco di problemi (primi tra tutti, il supporto unicode). Gli sviluppatori Windows più esperti hanno a disposizione alternative migliori, che però non sono oggetto di questa guida. cmd.exe è comunque sufficiente nella maggior parte dei casi, e sicuramente va bene per installare pacchetti Python.
le versioni più recenti di Python si installano nella directory protetta dei programmi (C:/Program Files... etc.). Questa è una buona cosa, tuttavia significa anche che per installare pacchetti spesso dovete agire con la password da amministratore. Occasionalmente, dovete quindi sapere come si apre una shell con accesso privilegiato: se non ve lo ricordate, vedete per esempio questo, oppure cercate qualcosa come "windows run elevated command prompt" su Google.

Vi ricordiamo infine che, per verificare che Python sia correttamente installato, basta invocarlo dalla shell:
C:/una/path/qualsiasi> python
Python [etc etc] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>>
Questo vi porta nella shell di Python (riconoscibile per il prompt >>>). Per uscire da Python e tornare alla shell di windows, basta scrivere exit() e premere "invio".
Se appare la shell di Python, siete a posto: Python esiste, ed è nella PATH di sistema. Viceversa, vuol dire che Python non è installato correttamente: questa eventualità non è coperta da questa guida (sorry, ma è già abbastanza lunga così).
Le librerie C++ Microsoft necessarie.

Nell'ipotesi più comune, potete saltare questa sezione.
Tuttavia è importante notare che, al fine di poter eseguire Python e i pacchetti Python con estensioni C su Windows (vedremo poi di cosa si tratta), è necessario che siano presenti i runtime C++ corrispondenti alla versione di Python utilizzata.
Ora, in genere queste librerie sono già installate su Windows, perché sono necessarie... un po' per tutto. L'unico possibile intoppo potrebbe essere legato a Python 3.5, che è compilato con Visual Studio 2015. Questo vuol dire che, se volete usare Python 3.5, avete una macchina non proprio recentissima, avete disabilitato gli aggiornamenti automatici, e non avete installato di recente nessun software che generosamente vi ha regalato i runtime di Visual C++ 2015, allora potreste non avere le librerie necessarie per far girare i pacchetti che vi servono.
Tuttavia anche questo intoppo si risolve da solo: al momento di installare Python 3.5, se l'installer non trova le librerie necessarie, semplicemente le aggiunge - ma vi chiede la password da amministratore. Quindi, l'intoppo potrebbe davvero verificarsi solo se, in aggiunta a tutte le condizioni appena viste, avete anche installato una qualche forma di versione "portable" di Python 3.5 che non interviene sulla vostra macchina (per esempio WinPython). Oppure, se avete volontariamente disinstallato il runtime in un momento successivo (!).
In genere, verificare la presenza del runtime C++ vuol dire semplicemente controllare la chiave di registro HKEY_LOCAL_MACHINE/SOFTWARE/Wow6432Node/Microsoft/VisualStudio, o verificare se esiste %WINDIR%/system32/msvcrXXX.dll (dove "XXX" è il numero di versione). Ovviamente, un modo ancora più semplice è invocare l'interprete python dalla shell: se non fallisce, vuol dire che probabilmente siete a posto.
Ricordiamo che le varie versioni di Python sono state compilate nel tempo con versioni diverse del runtime di Visual Studio:

Python 2.7 -> Visual C++ 2008 (ovvero, versione 9)
Python 3.3/3.4 -> Visual C++ 2010 (ovvero, versione 10.0)
Python 3.5 -> Visual C++ 2015 (ovvero, versione 14.0)

In caso di necessità, potete potete sempre installare a mano il runtime di Visual C++ 2015.
Pip e PyPI.

Chi sviluppa un pacchetto Python e lo vuole mettere a disposizione, nel 99% dei casi lo carica su PyPI. Il Python Package Index (modellato sul Cpan di Perl) è la più grande e ufficiale repository di pacchetti Python: potete sfogliarla con il vostro browser, ma una volta che avete trovato il pacchetto che cercate, e quindi sapete come si chiama, il modo giusto per installarlo è usare Pip, dal prompt della vostra shell.
Pip è il package manager di default, indispensabile e fondamentale. Se avete installato una versione di Python recente (almeno 2.7.9 oppure almeno 3.4), Pip è già disponibile. Altrimenti, potete installarlo seguendo queste istruzioni. Tuttavia, se non avete un Python abbastanza recente e dovete installare a mano Pip, il consiglio giusto sarebbe invece di procurarvi una versione più recente di Python.
Per verificare che Pip sia installato correttamente, basta invocarlo dalla shell:
C:/una/path/qualsiasi> pip

Usage:
  pip <command> [options]
  (etc. etc.)
Se compare la lista delle istruzioni per l'uso, siete a posto: Pip è installato ed è nella PATH di sistema. Altrimenti, vuol dire che Pip non è installato e/o non è nella PATH. In questo caso, se la vostra versione di Python è abbastanza recente da includere Pip, vuol dire che avete installato male Python: come già detto, questa eventualità non è coperta da questa guida.
Quando usate Pip per installare pacchetti, Pip si collega a PyPI, cerca e scarica il pacchetto richiesto. Per questo, avete naturalmente bisogno che la vostra shell abbia accesso a internet. Questo potrebbe non essere vero in caso di connessioni aziendali bloccate da un firewall, per esempio. Pip ha una opzione per specificare indirizzo e password di un server proxy, se è questo il vostro problema. In ogni caso, spesso non avete a disposizione le informazioni necessarie. Naturalmente ci sono soluzioni... (per esempio, passare da Cntlm), ma dovreste chiedervi fino a che punto potete agire senza violare policy aziendali.
Per quanto riguarda Pip, in ogni caso, la soluzione è semplice: se non potete connettervi direttamente a internet dalla shell, nulla vieta di cercare voi stessi manualmente il pacchetto che vi serve su PyPI, scaricarlo con il browser e installarlo localmente (vedremo tra poco che Pip è in grado di installare pacchetti anche da file locali). In ogni caso, questa guida assume che la vostra shell possa connettersi regolarmente a internet.
Se, durante l'uso, Pip si lamenta di non essere aggiornato, potete eventualmente provvedere. Ricordiamo (soprattutto per chi viene da Linux) che il comando corretto per questo è:
C:/una/path/qualsiasi> python -m pip install -U pip
Virtual environments.

Installato Python, e verificato che Pip esiste, in teoria potete cominciare a installare pacchetti Python. Tuttavia, in pratica è molto sconsigliato installare pacchetti "globalmente", ovvero nell'installazione Python "di base" del vostro sistema. La cosa giusta da fare è invece creare prima un "virtual environment" (per brevità "venv", d'ora in poi).
Un venv è una installazione "isolata" di Python, creata a partire dal Python "globale" che avete già installato. In concreto, è una directory separata in cui si copiano i file necessari all'esecuzione di Python e della sua libreria standard: successivamente, è possibile installare con Pip i pacchetti direttamente nel venv (ovvero, nella directory .../Lib/site-packages/ del venv, invece che del 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 buttar via il venv e ricominciare daccapo; etc.
La strategia abituale è quella di creare un venv separato per ciascun nuovo progetto. 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, è fondamentale creare un venv solo per lui.
Per mettervi in condizione di creare i venv, avete bisogno per prima cosa del pacchetto Virtualenvwrapper-win. Installatelo usando Pip (questa sarà una installazione "globale", naturalmente):
C:/una/path/qualsiasi> pip install virtualenvwrapper-win
Adesso dovete scegliere una directory in cui raccogliere tutti i venv che vorrete creare in futuro. Virtualenvwrapper-win usa di default %USERPROFILE%/Envs: se per voi va bene, non resta altro da fare. Tuttavia, potrebbe non essere la scelta più saggia. Su molte macchine Windows, %USERPROFILE% è intallato sul drive c:, che ha di solito meno spazio libero. Inoltre, sulle macchine aziendali spesso questa directory viene coperta dai backup periodici: se diventa troppo trafficata, il login può diventare lungo. Senza contare che non c'è assolutamente nessuna ragione di backuppare i venv, come vedremo. Valutate invece se non è più opportuno creare una directory nel drive d:, che molto spesso è una partizione con più spazio libero, e non coperta dai backup. In questo caso, create (per esempio) una directory d:/venvs. Per far sì che Virtualenvwrapper-win registri la vostra scelta, dovete anche creare una variabile d'ambiente WORKON_HOME e impostarla sul nome della directory che avete creato. Potete creare una variabile d'ambiente con la normale interfaccia di Windows (se non sapete come si fa, cercate su Google qualcosa come "windows create environment variable"; per esempio, potete seguire queste istruzioni). Oppure potete usare la shell:
C:/una/path/qualsiasi> setx WORKON_HOME "d:/venvs"
Dopo aver creato la variabile d'ambiente (in qualsiasi dei due modi), ricordatevi di riavviare la shell (in pratica, chiudetela e riapritene un'altra nuova). Infatti cmd.exe controlla le variabili d'ambiente solo una volta all'inizio, e quindi non ha modo di aggiornarsi. Una volta riaperta la shell, potete verificare che la variabile è stata effettivamente creata con echo %WORKON_HOME% (o addirittura con set, per vedere tutte le variabili esistenti).
Adesso siete pronti a creare il vostro primo venv: lo chiameremo "test".
C:/una/path/qualsiasi> mkvirtualenv test
Se adesso controllate il contenuto di d:/venvs/test, scoprirete che in pratica Virtualenvwrapper-win ha "clonato" il vostro Python lì dentro. Notate anche che il prompt della vostra shell è cambiato:
(test) C:/una/path/qualsiasi> 
Questo segnala che adesso state lavorando "nel contesto" del venv "test". Usate il comando deactivate per uscire dal venv, e workon test per rientrarvi. Se siete dentro il venv, quando invocate python dalla shell, state usando l'eseguibile che si trova nella directory del venv, e non quello "globale". E' facile rendersene conto:
(test) C:/una/path/qualsiasi> python
Python [etc etc] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys; sys.executable
'D:/venvs/test/scripts/python.exe'
Oltre a mkvirtualenv (per creare un venv), workon (per entrarci), deactivate (per uscirne), Virtualenvwrapper-win mette a disposizione altri strumenti per lavorare con i venv, che potete studiare leggendo la documentazione. E' opportuno solo ricordare che, per eliminare un venv, non dovete cancellare direttamente la sua directory: Virtualenvwrapper-win mantiene un registro dei venv creati, quindi occorre lasciar fare a lui, con rmvirtualenv <nome> (è possibile che, al termine dell'operazione, Virtualenvwrapper-win vi avverta che non è riuscito a cancellare alcuni file della directory: potete pensarci voi, a questo punto).
Quando lavorate nel contesto di un venv, potete fare tutto quello che normalmente fareste con la shell: cambiare directory, etc. Il contesto del venv è importante solo quando invocate l'eseguibile di Python. Per una ragione che vi sarà più chiara tra poco, è importante notare che non bisognerebbe mai manipolare direttamente nulla, dentro la directory del venv (creare o modificare file, etc.). Il contenuto di un venv dovrebbe dipendere solo da Virtualenvwrapper-win e dai pacchetti che installerete con Pip.
Una nota per concludere: Virtualenvwrapper-win funziona solo con la shell cmd.exe, ma non con Powershell.
Lavorare con Pip e i venv.

Adesso che sapete creare i venv, potete usare Pip per installare pacchetti. Per prima cosa, create un venv nuovo (mkvirtualenv test) e/o entrateci se lo avete già creato (workon test).
Come primo esempio, proviamo a installare Arrow (un pacchetto per la gestione delle date):
(test) C:/una/path/qualsiasi> pip install arrow
[...]
(test) C:/una/path/qualsiasi> python
Python [etc etc] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import arrow
>>> print(arrow.utcnow()) # funziona!
Niente di difficile. Se adesso uscite dal venv, e provate di nuovo ad aprire una shell Python e importare Arrow, otterrete invece un  ImportError. Come promesso, Arrow è stato installato solo nel venv, e non nel Python "globale".
La stessa cosa, ovviamente, vale per i vostri script. Create un modulo Python vuoto (supponiamo, d:/my_scripts/arrow_test.py), e scriveteci dentro:
import arrow
print(arrow.utcnow())
Adesso se lo eseguite da dentro il venv, funziona:
(test) d:/my_scripts> python arrow_test.py
[...]
Ma fuori dal venv, no:
(test) d:/my_scripts> deactivate
d:/my_scripts> python arrow_test.py
[...]
ImportError: No module named 'arrow'
Una nota importante: a questo punto dovrebbe essere ovvio, ma ricordiamo comunque che "fare doppio clic" su uno script Python non è il modo giusto per eseguirlo. Gli script Python si invocano dalla shell - è l'unico modo per passare eventuali argomenti allo script, per vedere il traceback degli errori se qualcosa va storto, etc. L'utilizzo dei venv, poi, costringe a usare la shell: facendo doppio clic, lo script viene interpretato dal Python "globale", e pertanto tutti i pacchetti installati nel venv non saranno disponibili, e lo script fallirà.
Un altra nota importante. Dalla versione 3.3 di Python, è stato introdotto il launcher py.exe, una comoda utility che permette, tra l'altro, di gestire installazioni multiple di Python. Purtroppo inizialmente py non si "accorgeva" dei venv: se lo usavate dentro un venv, py linkava comunque al Python "globale". Di conseguenza, fuori da un venv era possibile usare py my_script.py per eseguire uno script; ma dentro un venv bisognava tornare a scrivere python my_script.py. Questo baco è stato corretto solo nella versione 3.5: se avete una versione abbastanza recente di Python, potete quindi usare py anche dentro i venv.
La documentazione completa di Pip spiega nel dettaglio tutte le opzioni possibili. E' importante ricordare, oltre a pip install, anche pip uninstall <package> e pip upgrade <package>.
pip install <package> fa molto lavoro dietro le quinte: cerca la versione più aggiornata, adeguata alla nostra versione di Python e al nostro sistema operativo; poi controlla che il pacchetto non abbia a sua volta delle "dependencies" che non abbiamo ancora installato; scarica tutti i pacchetti necessari, e li installa. pip install è un comando complesso, e la documentazione illustra tutte le opzioni disponibili. Una delle più importanti è la possibilità di specificare la versione del pacchetto da installare, in modo più o meno preciso. Per esempio,
pip install arrow==0.4.4
pip install 'arrow>=0.5'

e così via.
Un'altra possibilità importante è quella di installare, tutti in una volta, i pacchetti elencati in un file di testo (che per consuetudine viene chiamato requirements.txt):
pip install -r requirements.txt
Il formato di un requirements.txt può essere molto semplice (in pratica, un elenco di pacchetti) o più raffinato - rimandiamo alla documentazione per tutte le sottigliezze. In modo speculare, pip freeze elenca tutti i pacchetti che avete installato finora: di conseguenza, basta un pip freeze > requirements.txt per generare un file di requirements.
Una strategia molto comune, al momento di iniziare un nuovo progetto, è di creare un venv apposta. Man mano che si installano dei nuovi pacchetti necessari al progetto, si rigenera il requirements.txt con pip freeze. Il file dei requirements è quindi tutto ciò che occorre per definire l'"ambiente Python" necessario a far funzionare il codice di quel progetto. Il venv si può distruggere e ricreare da zero, con un semplice pip install -r requirements.txt. Abbiamo già detto che è importante non manipolare mai direttamente la directory del venv, e questo è appunto il motivo: tutto il contenuto del venv deve dipendere esclusivamente da un requirements.txt. Il progetto (i moduli Python che scriviamo, la documentazione, i file di configurazione e accessori...) risiedono in una directory separata dal venv. Anche il file dei requirements risiede nella directory del progetto (che probabilmente è monitorata con Git o con un altro version control manager).
Installare pacchetti con estensioni C.

La procedura che abbiamo descritto fin qui funziona per installare pacchetti "pure Python". Ma per esempio, se proviamo pip install numpy (per installare Numpy, la celebre suite per il calcolo scientifico), il risultato sarà solo una serie di messaggi di errore piuttosto complicati, ma che in sostanza ci avvertono che non è possibile "compilare" i pacchetti necessari.
Che cosa è successo? Molti pacchetti, in realtà, non sono scritti solo in Python, ma ospitano anche qualche estensione scritta in C. Le estensioni in C devono essere compilate, al momento dell'installazione. Questo non è un problema sui sistemi Linux, che tradizionalmente hanno un compilatore "di default" pronto all'uso: in questo caso, Pip si rivolge al compilatore, compila le estensioni C, e installa il pacchetto senza problemi.
Windows invece non ha un compilatore di default, e quindi Pip scarica correttamente il pacchetto giusto, ma al momento di compilare le estensioni non sa più come procedere. In generale, possiamo rimediare seguendo una delle due strade:


installiamo un compilatore C, e compiliamo a mano le estensioni che ci servono. In linea di principio, questa è una strada perfettamente percorribile. Tuttavia, compilare su Windows richiede un po' di esperienza e capacità di affrontare corner case fastidiosi; e inoltre, diciamolo, nessuno ha davvero voglia di mettersi a fare questo lavoro. Siccome questa è una guida di base, non copriremo qui questi argomenti (magari potrebbe essere l'argomento per una guida futura).


nella maggior parte dei casi, qualcuno ha già fatto il lavoro al posto nostro. Si tratta quindi di trovare e scaricare un pacchetto con le estensioni già compilate, che Pip può quindi installare senza problemi.


Questa guida spiega come percorrere la seconda strada - ma prima, una legittima domanda: perché gli sviluppatori non distribuiscono su PyPI direttamente i pacchetti con le estensioni già compilate? In primo luogo, questa possibilità è arrivata solo di recente, quando il nuovo sistema di packaging adottato da Python (le Wheel) ha permesso di pacchettizzare anche i file binari compilati. Ma soprattutto, è normale che gli sviluppatori non abbiano voglia di supportare diverse versioni dello stesso pacchetto, pre-compilate per ciascuna diversa piattaforma. Al più, è possibile trovare le wheel compilate solo per le piattaforme che gli sviluppatori ritengono più interessanti o accessibili per loro: per esempio, su PyPI potete trovare delle wheel precompilate di Numpy... per il MacOS!
Una volta trovato il pacchetto precompilato che ci interessa, l'installazione è appena un po' più complicata del normale. Occorre prima scaricare manualmente il file: siccome finirete per installare certi pacchetti più volte in diversi venv, può essere utile conservarli tutti in una directory apposita, per esempio d:/venvs/packages. Fatto questo, Pip è perfettamente in grado di installare anche da un file locale:
pip install d:/venvs/packages/nome_del_package.whl
E questo dovrebbe essere tutto! Notate che i nomi delle wheel sono significativi: se rinominate il file, la wheel non funzionerà più.
Se adesso chiedete un pip freeze, noterete che il pacchetto che avete installato a mano è regolarmente elencato insieme agli altri. Di conseguenza, potete anche generare un normale file di requirements (pip freeze > requirements.txt). Tuttavia, se in futuro volete usare il file di requirements per re-installare l'ambiente del venv (pip install -r requirements.txt), questo potrebbe non funzionare: Pip cercherebbe i pacchetti richiesti su PyPI, e questi non si installerebbero perché non sono quelli pre-compilati (in realtà, Pip mantiene una cache dei pacchetti recenti installati: quindi potrebbe prima cercare nella cache, trovare il pacchetto "giusto" e installarlo senza problemi. Ma non potete fare affidamento su questo nel caso generale).
L'unica soluzione è correggere il file requirements.txt, e specificare il pacchetto locale dove necessario: il vostro file potrebbe quindi avere questo aspetto:
# file requirements.txt

# pacchetti "pure python" da cercare su PyPI:
arrow==0.5
# etc etc

# pacchetti binari da installare localmente:
# numpy:
d:/venvs/packages/numpy-1.10.4+mkl-cp34-none-win_amd64.whl
# etc etc

Potete chiamare requirements_local.txt questo file di requirements specifico per il vostro sistema, e generare un normale requirements.txt da includere nel vostro progetto se intendete pubblicarlo. Di regola, solo il requirements.txt dovrebbe essere monitorato da Git (o altro version control manager) anche per evitare di pubblicare dati relativi alla struttura del vostro file system locale.
Dove trovare i pacchetti precompilati da installare.

Una volta capito come si installano le wheel precompilate, resta da vedere dove è possibile trovarle.
Va detto che potrebbe essere leggermente più complicato trovare wheel compilate per Python 3.5. Come abbiamo visto, questa versione di Python è stata compilata per la prima volta con Visual Studio 2015: di conseguenza, anche se un pacchetto, per quanto riguarda il codice Python, potrebbe essere perfettamente compatibile tra Python 3.4 e Python 3.5, tuttavia avrebbe ugualmente bisogno di essere ri-compilato per le sue estensioni C (e per giunta usando un compilatore molto recente, che non tutti hanno interesse a installare).
In ogni caso, ci sono diverse opzioni da tentare.


La wheel precompilata per la vostra piattaforma è già su PyPI. Questa è in realtà una opzione-zero che dovreste aver già controllato, perché in questo caso pip install funziona senza problemi. Tuttavia occasionalmente su PyPI si trovano altre distribuzioni precompilate, solo non come wheel (tipicamente degli .exe, cfr. sotto, punto 5): quindi, anche se pip install fallisce, una ricerca manuale su PyPI è comunque la prima cosa da fare.


Il pacchetto "problematico" è una dependency di un altro pacchetto che state cercando di installare da PyPI. Questo è un caso frequente: per esempio, se cercate di installare Blaze (una libreria di calcolo orientata ai Big Data) con pip install blaze, scoprirete che Pip raccoglie e installa anche una buona ventina di altri pacchetti richiesti. Purtroppo tra questi ci sono anche Numpy e Pandas, entrambi da compilare. In casi del genere, prendete nota dei pacchetti che Pip non riesce ad installare da PyPI, cercateli e installateli manualmente, e poi ripetete l'installazione del pacchetto di partenza. Per esempio, una volta installati Numpy e Pandas, Pip installa senza problemi Blaze da PyPI, perché Blaze, di per sé, è un pacchetto "pure Python".


La wheel precompilata si trova sulla raccolta non ufficiale di Christoph Gohlke. Questo sito è una vera miniera d'oro per chi sviluppa in Python su Windows. Il buon Chris mantiene da anni una raccolta di decine di pacchetti precompilati, per varie versioni di Python e diverse piattaforme (32 e 64 bit). Semplicemente, cercate il pacchetto che vi interessa con ctrl+F nel vostro browser, assicuratevi di scaricare la versione giusta per voi, e installate. Questo sito è assolutamente da tenere nei bookmark.


La wheel precompilata si trova sul sito dello sviluppatore. Questo è davvero raro: se lo sviluppatore si è dato la pena di produrre una wheel precompilata, allora deve averla messa anche su PyPI, e voi dovreste già averla trovata con pip install. Talvolta però si trovano altre indicazioni utili, per esempio link a contributori del progetto che mantengono versioni compilate separate, etc.


Sul sito dello sviluppatore (o siti collegati di contributori etc.; talvolta, anche su PyPI) si trova non la wheel precompilata, ma comunque un installer .exe. Questa era la tecnica più diffusa fino a poco tempo fa, anche perché era in pratica l'unico modo di mettere a disposizione pacchetti precompilati per Windows. L'aspetto negativo è che questi .exe si installano solo "globalmente", ignorando i venv. L'aspetto positivo è che si tratta in genere solo di pacchetti .egg (il vecchio modo di creare pacchetti in Python) raccolti in un file .zip eseguibile: pertanto è facile convertirli in moderne wheel. Tutto quello che occorre, una volta scaricato il pacchetto, è dare il comando wheel convert pacchetto.exe per ottenere un wheel installabile poi con Pip. La libreria necessaria per l'operazione, Wheel, dovrebbe essere installata di default con Pip. Altrimenti, basta installarla con pip install wheel. Se la trasformazione da .exe a .whl non riesce, significa che l'installer non è compatibile (probabilmente perché fa delle cose più complesse mentre installa il pacchetto, come scrivere nel registro di configurazione, etc.).


Ci sono casi (anche importanti: tra gli altri PyQt5, Panda3D) che non sono facilmente "trattabili" con queste tecniche. Talvolta è possibile ricorre a qualche soluzione brutale (per esempio: installare globalmente il pacchetto e poi copiare/linkare tutte le librerie nel venv, facendo specialmente attenzione a dove dovrebbero essere messi i .dll binari. Oppure, installare WinPython in modalità "portable" e copiare la directory che ci interessa nel nostro venv...). Ma spesso occorre rassegnarsi a installare questi pacchetti globalmente. Naturalmente è sempre possibile provare a compilare manualmente il pacchetto: ma se nessuno l'ha fatto finora (a partire da Chris Gohlke), ci sono ottime probabilità che si tratti di un'operazione complessa.