Vorrei solo evitare l'uso di virtualenv
dopo Python3.3 + e invece utilizzare la libreria standard fornita venv
. Per creare un nuovo ambiente virtuale, digitare:
$ python3 -m venv <MYVENV>
virtualenv
tenta di copiare il binario Python nella directory bin dell'ambiente virtuale. Tuttavia, non aggiorna i collegamenti ai file di libreria incorporati in quel file binario, quindi se si crea Python dall'origine in una directory non di sistema con nomi di percorso relativi, il binario Python si interrompe. Dato che è così che rendi una copia distribuibile di Python, è un grosso difetto. BTW per ispezionare i collegamenti ai file della libreria incorporata su OS X, utilizzare otool
. Ad esempio dall'ambiente virtuale, digitare:
$ otool -L bin/python
python:
@executable_path/../Python (compatibility version 3.4.0, current version 3.4.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.0.0)
Di conseguenza eviterei virtualenvwrapper
e pipenv
. pyvenv
è deprecato. pyenv
sembra essere usato spesso dove virtualenv
viene utilizzato, ma vorrei stare lontano da esso anche perché penso che venv
faccia anche quello per cui pyenv
è stato progettato.
venv
crea ambienti virtuali nella shell che sono freschi e in modalità sandbox , con librerie installabili dall'utente ed è sicuro per più pitoni . Fresco perché gli ambienti virtuali iniziano solo con le librerie standard fornite con Python, è necessario installare nuovamente tutte le altre librerie pip install
mentre l'ambiente virtuale è attivo. Sandbox perché nessuna di queste nuove installazioni di librerie è visibile al di fuori dell'ambiente virtuale, quindi è possibile eliminare l'intero ambiente e ricominciare senza preoccuparsi di influire sull'installazione di Python di base. Librerie installabili dall'utente perché la cartella di destinazione dell'ambiente virtuale viene creata senzasudo
in alcune directory che già possiedi, quindi non avrai bisogno delle sudo
autorizzazioni per installare le librerie al suo interno. Infine è multi-python sicuro , poiché quando gli ambienti virtuali si attivano, la shell vede solo la versione di Python (3.4, 3.5 ecc.) Che è stata utilizzata per creare quell'ambiente virtuale.
pyenv
è simile al fatto venv
che ti consente di gestire più ambienti Python. Tuttavia, con pyenv
te non è possibile eseguire il rollback delle installazioni delle librerie su un certo stato iniziale e probabilmente avrai bisogno dei admin
privilegi per aggiornare le librerie. Quindi penso che sia anche meglio usare venv
.
Negli ultimi due anni ho riscontrato molti problemi nei sistemi di compilazione (pacchetti emacs, compilatori di applicazioni standalone python, programmi di installazione ...) che alla fine si sono risolti con problemi virtualenv
. Penso che Python sarà una piattaforma migliore quando elimineremo questa opzione aggiuntiva e useremo solo venv
.