Share
Molti di noi lavorano su più progetti Python contemporaneamente. Più progetti possono dipendere da diverse versioni della stessa libreria. Questo è un problema. Anche se si lavora con un singolo progetto e lo si distribuisce in produzione, è possibile che si verifichino dei problemi, poiché il sistema Python sul server di produzione potrebbe cambiare a causa dell'upgrade del sistema operativo o della patch di sicurezza e l'applicazione potrebbe non riuscire. In generale, vuoi il pieno controllo sull'ambiente Python dei tuoi progetti. Entra in ambienti virtuali ...
L'idea di base di un ambiente virtuale è di avere un interprete Python e i suoi pacchetti di siti separati da quello di sistema. Inoltre, puoi averne molti. Questo risolve entrambi i problemi. È possibile assegnare un ambiente virtuale separato con le proprie dipendenze per ogni progetto e dimenticare i conflitti con altri progetti e il Python del sistema.
In questo tutorial imparerai i concetti dietro gli ambienti virtuali e come crearli e usarli, e scoprirai varie alternative per situazioni speciali.
Il pacchetto virtualenv supporta questo concetto. È possibile installare virtualenv utilizzando pip installa virtualenv.
Una volta installato virtualenv, è possibile iniziare a creare ambienti virtuali. Creiamo due ambienti chiamati "venv_1" e "venv_2".
~> virtualenv ~ / venv_1 Usando il prefisso reale '/usr/local/Cellar/python/2.7.10/Framework/Python.framework/Versions/2.7' Nuovo eseguibile python in /Users/gigi/venv_1/bin/python2.7 Anche creazione di un eseguibile in / Users / gigi / venv_1 / bin / python Installazione di setuptools, pip, wheel ... terminato. ~> virtualenv ~ / venv_2 Usando il prefisso reale '/usr/local/Cellar/python/2.7.10/Framework/Python.framework/Versions/2.7' Nuovo eseguibile python in /Users/gigi/venv_2/bin/python2.7 Anche creazione di un eseguibile in / Users / gigi / venv_2 / bin / python Installazione di setuptools, pip, wheel ... terminato.
Vediamo cosa è successo.
~> ls -la ~ / venv_1 totale 16 drwxr-xr-x 7 gigi staff 238 mar 29 23:12. drwxr-xr-x + 254 gigi staff 8636 29 mar 23: 12 ... lrwxr-xr-x 1 gigi staff 79 mar 29 23:12 .Python -> /usr/local/Cellar/python/2.7.10/Framework/Python. framework / Versions / 2.7 / Python drwxr-xr-x 16 gigi staff 544 mar 29 23:12 bin drwxr-xr-x 3 gigi staff 102 mar 29 23:12 include drwxr-xr-x 3 gigi staff 102 mar 29 23: 12 lib -rw-r - r-- 1 gigi staff 60 mar 29 23:12 pip-selfcheck.json
All'interno della sottodirectory "bin", troverai alcuni file eseguibili e symlink. Questi includono lo stesso interprete Python, pip, easy_install e, soprattutto, alcuni script di attivazione.
~> ls -la ~ / venv_1 / bin totale 136 drwxr-xr-x 16 gigi staff 544 mar 29 23:12. drwxr-xr-x 7 gigi staff 238 mar 29 23: 12 ... -rw-r - r-- 1 gigi staff 2077 mar 29 23:12 attiva -rw-r - r-- 1 gigi staff 1019 mar 29 23 : 12 activate.csh -rw-r - r-- 1 gigi staff 2217 29 mar 29 23:12 activate.fish -rw-r - r-- 1 gigi staff 1137 29 mar 23:12 activate_this.py -rwxr- xr-x 1 gigi staff 249 mar 29 23:12 easy_install -rwxr-xr-x 1 gigi staff 249 mar 29 23:12 easy_install-2.7 -rwxr-xr-x 1 gigi staff 221 mar 29 23:12 pip -rwxr- xr-x 1 gigi staff 221 mar 29 23:12 pip2 -rwxr-xr-x 1 gigi staff 221 mar 29 23:12 pip2.7 lrwxr-xr-x 1 gigi staff 9 mar 29 23:12 python -> python2. 7 -rwxr-xr-x 1 gigi staff 2336 29 mar 23:12 python-config lrwxr-xr-x 1 gigi staff 9 mar 29 23:12 python2 -> python2.7 -rwxr-xr-x 1 gigi staff 12744 mar 29 23:12 python2.7 -rwxr-xr-x 1 gigi staff 228 mar 29 23:12 ruota
Lo script di attivazione è la chiave. Per attivare uno specifico ambiente virtuale, si genera lo script di attivazione, come in: fonte ~ / venv_1 / bin_activate. L'effetto è l'impostazione di una serie di variabili di ambiente e la modifica della richiesta al nome dell'ambiente virtuale attivato. Aggiunge anche a disattivare() funzione shell che resetterà tutto. Una volta attivato un ambiente virtuale, digitando pitone lancerà il suo Python con le sue dipendenze.
~> source ~ / venv_1 / bin / activate (venv_1) ~> quale python / Users / gigi / venv_1 / bin / python (venv_1) ~>
Disattivi:
(venv_1) ~> deactivate ~> quale python / usr / local / bin / python
Se sono installati più interpreti Python installati sui sistemi, è possibile specificare quale utilizzare per il proprio ambiente virtuale utilizzando -p opzione. Ecco un ambiente virtuale Python 3:
~> virtualenv ~ / venv_3 -p / usr / local / bin / python3 Esecuzione virtualenv con interprete / usr / local / bin / python3 Utilizzo del prefisso di base '/usr/local/Cellar/python3/3.5.1/Framework/Python.framework /Versions/3.5 'Nuovo eseguibile python in /Users/gigi/venv_3/bin/python3.5 Creazione anche eseguibile in / Users / gigi / venv_3 / bin / python Installazione di setuptools, pip ... done. ~> source ~ / venv_3 / bin / activate (venv_3) ~> python Python 3.5.1 (predefinito, 9 gennaio 2016, 19:28:52) [GCC 4.2.1 compatibile Apple LLVM 7.0.0 (clang-700.1.76 )] su darwin Digitare "help", "copyright", "credits" o "license" per ulteriori informazioni. >>>
Virtualenv funziona anche su PYPY.
~> virtualenv ~ / venv_pypy -p 'which pypy' Esecuzione virtualenv con interprete / usr / local / bin / pypy Nuovo eseguibile pypy in / Users / gigi / venv_pypy / bin / pypy Installazione di setuptools, pip ... done. ~> source ~ / venv_pypy / bin / activate (venv_pypy) ~> python Python 2.7.10 (5f8302b8bf9f53056e40426f10c72151564e5b19, Feb 11 2016, 20:39:39) [PyPy 4.0.1 con GCC 4.2.1 Compatibile Apple LLVM 7.0.2 ( clang-700.1.81)] su darwin Digitare "help", "copyright", "credits" o "license" per ulteriori informazioni. >>>>
È possibile passare direttamente da un ambiente all'altro senza disattivare prima:
(venv_3) ~> source ~ / venv_2 / bin / activate (venv_2) ~> quale python / Users / gigi / venv_2 / bin / python
OK. Vediamo come utilizzare due diverse versioni dello stesso pacchetto in due diversi ambienti virtuali. Questo è semplice come l'attivazione di ogni ambiente e l'installazione della versione desiderata. Gli ambienti sono totalmente indipendenti, quindi il fatto che ci sia una versione diversa in un altro ambiente è un non-problema.
Installiamo la versione 1.0 del pacchetto sh in "venv_1".
(venv_1) ~> pip install sh == 1.0 Raccolta di sh == 1.0.0 Download di sh-1.0.tar.gz Costruzione di ruote per pacchetti raccolti: sh Esecuzione di setup.py bdist_wheel per sh ... done Memorizzato nella directory: / Users / gigi / Libreria / Caches / pip / wheels / f9 / fb / a1 / 383f6dc2834b319a788a006d3ab7cc014ee852485f00b9e8c3 Installato con successo sh Installazione dei pacchetti raccolti: sh Installato correttamente sh-1.0 (venv_1) ~> freeze del pip | grep sh sh == 1.0
Passiamo a "venv_2" e installiamo la versione 1.11.
(venv_1) ~> source ~ / venv_2 / bin / activate (venv_2) ~> pip install sh == 1.11 Raccolta sh == 1.11 Download sh-1.11.tar.gz Costruire ruote per pacchetti raccolti: sh Esecuzione setup.py bdist_wheel per sh ... done Memorizzato nella directory: / Users / gigi / Library / Caches / pip / wheels / ba / 4f / a5 / ec77d662c3bf38f564b5ab16f1f3dbb9575922826fe810961c Costruito con successo sh Installazione dei pacchetti raccolti: sh Installato correttamente sh-1.11 (venv_2) ~> freeze del pip | grep sh sh == 1.11
Ora, torniamo a "venv_1" e verifichiamo che la sua versione del pacchetto sh sia ancora 1.0.
(venv_2) ~> source ~ / venv_1 / bin / activate (venv_1) ~> pip freeze | grep sh sh == 1.0 (venv_1) ~>
Tutto ciò che attiva, disattiva e cambia può diventare vecchio dopo un po '. Se gestisci molti ambienti virtuali, può andare fuori controllo. Ecco dove entra virtualenvwrapper. Virtualenvwrapper ti consente di elencare, creare, eliminare e copiare ambienti virtuali. Permette anche di cambiare facilmente gli ambienti.
Ecco tutti i comandi:
~> virtualenvwrapper virtualenvwrapper è un insieme di estensioni dello strumento virtualenv di Ian Bicking. Le estensioni includono wrapper per la creazione e l'eliminazione di ambienti virtuali e in caso contrario la gestione del flusso di lavoro di sviluppo, rendendo più semplice lavorare su più di un progetto alla volta senza introdurre conflitti nelle loro dipendenze. Per ulteriori informazioni, consultare la documentazione: http://virtualenvwrapper.readthedocs.org/en/latest/command_ref.html Comandi disponibili: add2virtualenv: aggiungi la directory al percorso di importazione allvirtualenv: esegui un comando in tutto il cdproject di virtualenvs: cambia directory in il progetto attivo cdsitepackages: cambia nella directory dei siti-siti cdvirtualenv: passa alla directory $ VIRTUAL_ENV cpvirtualenv: duplica il nome virtualenv per creare un nuovo lssitepackages: elenca i contenuti della directory dei siti del sito lsvirtualenv: list virtualenvs mkproject: crea un nuovo directory di progetto e il relativo virtualenv mktmpenv: creare un virtualenv mkvirtualenv temporaneo: Creare una nuova virtualenv in $ WORKON_HOME rmvirtualenv: Rimuovere un virtualvvvvvvvvvvvvvvvvvvvvvvvvvvvg: associare una directory di progetto con un virtualvvvvvvvvtualvv: visualizzare i dettagli di un singolo virtualenv toggleglobalsitepackages: ruotare l'accesso al sito globale -packages on / off virtualenvwrapper: mostra questo messaggio di aiuto wipeenv: remove tutti i pacchetti installati nell'attuale lavoro virtualenv: elenca o modifica virtualenvs funzionanti
Io uso praticamente due comandi: mkvirtualenv e lavorare su. Tutti gli ambienti virtuali sono creati sotto ~ / .Virtualenvironments.
Ecco come creare un nuovo ambiente virtuale:
~> mkvirtualenv venv Nuovo eseguibile python in venv / bin / python2.7 Creazione anche eseguibile in venv / bin / python Installazione di setuptools, pip ... terminato. (venv) ~>
Questo è simile a virtualenv, ma non si specifica una directory, solo un nome. Il tuo nuovo ambiente è qui:
(venv) ~> tree -L 2 ~ / .virtualenvs / venv / /Users/gigi/.virtualenvs/venv/ ├── bin │ ├── attiva │ ├── activate.csh │ ├── activate.fish │ ├── activate_this.py │ ├── easy_install │ ├── easy_install-2.7 │ ├── get_env_details │ ├── pip │ ├── pip2 │ ├── pip2.7 │ ├── postattivato │ ├── postdeactivate │ ├── preattiv │ ├── predectate │ ├── python -> python2.7 │ ├── python2 -> python2.7 │ └── python2.7 ├── include │ └── python2.7 -> /usr/local/Cellar/python/2.7.10/Framework/Python.framework/Versions/2.7/include/python2.7 └── lib └── python2.7
Per passare da un ambiente all'altro, si utilizza il lavorare su comando, che senza argomenti elenca solo tutti gli ambienti virtuali. Ne ho parecchi:
(venv) ~> workon acme_server conman curr-gen nupic over-achiever pandas prime_hunter pypy quote-servizi venv work (venv) ~> workon conman (conman) ~>
Virtualenv-Burrito è un progetto per installare virtualenv e virtualenvwrapper in un unico comando.
Il modulo venv è stato aggiunto a Python 3.3 e fornisce la creazione e la gestione di ambienti virtuali integrati proprio come virtualenv. Il comando per creare ambienti virtuali è pyenv. Altrimenti è abbastanza simile a virtualenv.
Gli ambienti virtuali sono molto utili per isolare le dipendenze tra diversi progetti. Ma questo non si estende alle librerie native. Molte estensioni C dipendono da particolari versioni di librerie native e quelle non possono essere specifiche dell'ambiente virtuale.
Conda può affrontare questo problema. È un sistema di gestione dei pacchetti che gestisce tutte le dipendenze, non solo le dipendenze Python. Può anche essere usato per il confezionamento di software non Python.
Devi usare ambienti virtuali? Non proprio. Se per qualche motivo non ti piace la magia degli ambienti virtuali, ci sono altre opzioni.
La funzionalità di un ambiente virtuale è piuttosto semplice. Se hai bisogno di controllo totale, puoi farlo da solo e copiare esattamente il sottoinsieme di strumenti e pacchetti che desideri in una struttura di directory di destinazione, impostare alcune variabili di ambiente e sei pronto per andare.
Se si cuociono le applicazioni in un contenitore docker o in un'immagine cloud, ci sarà un solo progetto e potrebbe non essere necessario un ambiente virtuale nel mezzo. Puoi semplicemente costruire sul sistema Python, assicurandoti che non venga modificato.
Se tutto quello che ti interessa è testare il tuo codice sotto diversi interpreti e ambienti, allora Tox può fare tutto il lavoro pesante per te. Continuerà a utilizzare ambienti virtuali sotto le copertine, ma non dovrai gestirli.
Esistono alcune best practice relative al packaging e all'ambiente virtuale che sono emerse nel tempo per robusti sistemi Python.
Pinning significa specificare con precisione le versioni delle tue dipendenze. Se esce una nuova versione e si installa l'applicazione su un nuovo server, si continuerà a utilizzare la versione su cui si è verificato e che funziona, e non l'ultima e la più grande. Qui c'è uno svantaggio: devi aggiornare le versioni in modo esplicito se vuoi tenere il passo con i progressi compiuti dalle tue dipendenze, ma di solito ne vale la pena.
Affidarsi alla versione di sistema è una cattiva pratica, perché ci sono altri strumenti che si basano su di essa, e se si avvia l'aggiornamento dei pacchetti di sistema, è possibile interromperli. Potresti anche essere influenzato dagli aggiornamenti di sicurezza che modificano i pacchetti di sistema, o in generale se vuoi aggiornare il tuo sistema operativo potresti scoprire che il sistema Python ora è diverso.
PyPI potrebbe essere inattivo. Se devi preparare una nuova immagine e non puoi accedere a PyPI, sei nei guai. Devpi è una buona opzione per evitare la frustrazione.
Esistono molte opzioni per la gestione di più progetti Python sulla stessa macchina senza conflitti. Scopri quale opzione è la migliore per te e usala. È facile e veloce creare ambienti virtuali. Non esitate a sfruttare questo utile strumento. Se hai esigenze particolari, ci sono anche molte soluzioni.
Accentsconagua