Python 3.3 include nella sua libreria standard il nuovo pacchetto venv. Cosa fa e in cosa differisce da tutti gli altri pacchetti che sembrano corrispondere alla regex (py)?(v|virtual|pip)?env?

Pacchetti PyPI non presenti nella libreria standard:

• virtualenvè uno strumento molto popolare che crea ambienti Python isolati per le librerie Python. Se non hai familiarità con questo strumento, ti consiglio vivamente di impararlo, in quanto è uno strumento molto utile e farò un confronto con esso per il resto di questa risposta.

  Funziona installando un gruppo di file in una directory (ad esempio:) env/, e quindi modificando la PATHvariabile di ambiente per prefissarla con una bindirectory personalizzata (ad esempio:) env/bin/. Una copia esatta del binario pythono python3è collocata in questa directory, ma Python è programmato per cercare prima le librerie relative al suo percorso, nella directory di ambiente. Non fa parte della libreria standard di Python, ma è ufficialmente benedetto dal PyPA (Python Packaging Authority). Una volta attivato, è possibile installare i pacchetti nell'ambiente virtuale utilizzando pip.

• pyenvviene utilizzato per isolare le versioni di Python. Ad esempio, potresti voler testare il tuo codice con Python 2.7, 3.6, 3.7 e 3.8, quindi avrai bisogno di un modo per passare da uno all'altro. Una volta attivato, prefigura la PATHvariabile d'ambiente con ~/.pyenv/shims, dove ci sono file speciali corrispondenti ai comandi Python ( python, pip). Queste non sono copie dei comandi forniti da Python; sono script speciali che decidono al volo quale versione di Python eseguire in base alla PYENV_VERSIONvariabile di ambiente, al .python-versionfile o al ~/.pyenv/versionfile. pyenvrende anche il processo di download e l'installazione di più versioni di Python più facile, usando il comando pyenv install.

• pyenv-virtualenvè un plug-in pyenvdello stesso autore pyenv, per permetterti di usarlo pyenve virtualenvallo stesso tempo comodamente. Tuttavia, se stai utilizzando Python 3.3 o versioni successive, pyenv-virtualenvproverà a eseguirlo python -m venvse è disponibile, anziché virtualenv. È possibile utilizzare virtualenve pyenvinsieme senza pyenv-virtualenv, se non si desidera le funzionalità di convenienza.

• virtualenvwrapperè un insieme di estensioni a virtualenv(vedi documenti ). Ti dà comandi come mkvirtualenv, lssitepackagese soprattutto workonper passare da una virtualenvdirectory all'altra. Questo strumento è particolarmente utile se si desidera più virtualenvdirectory.

• pyenv-virtualenvwrapperè un plugin per pyenvlo stesso autore pyenv, per integrarsi comodamente virtualenvwrapperin pyenv.

• pipenvmira a combinare Pipfile, pipe virtualenvin un solo comando sulla riga di comando. La virtualenvdirectory viene generalmente inserita ~/.local/share/virtualenvs/XXX, XXXessendo un hash del percorso della directory del progetto. Ciò è diverso da virtualenvdove la directory si trova in genere nella directory di lavoro corrente. pipenvè pensato per essere utilizzato durante lo sviluppo di applicazioni Python (al contrario delle librerie). Ci sono alternative pipenv, come poetry, che non elencherò qui poiché questa domanda riguarda solo i pacchetti che hanno un nome simile.

Biblioteca standard:

• pyvenvè uno script fornito con Python 3 ma deprecato in Python 3.6 poiché aveva problemi (per non parlare del nome confuso). In Python 3.6+, l'equivalente esatto è python3 -m venv.

• venvè un pacchetto fornito con Python 3, che puoi eseguire usando python3 -m venv(anche se per qualche ragione alcune distro lo separano in un pacchetto distro separato, come python3-venvsu Ubuntu / Debian). Ha lo stesso scopo di virtualenv, ma ha solo un sottoinsieme delle sue caratteristiche ( vedere un confronto qui ). virtualenvcontinua ad essere più popolare di venv, soprattutto perché il primo supporta sia Python 2 che 3.

Raccomandazione per i principianti:

Questa è la mia raccomandazione personale per i principianti: inizia imparando virtualenve pip, strumenti che funzionano con Python 2 e 3 e in una varietà di situazioni, e raccogli altri strumenti quando inizi a averne bisogno.

Vorrei solo evitare l'uso di virtualenvdopo Python3.3 + e invece utilizzare la libreria standard fornita venv. Per creare un nuovo ambiente virtuale, digitare:

$ python3 -m venv <MYVENV>  

virtualenvtenta 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 virtualenvwrappere pipenv. pyvenvè deprecato. pyenvsembra essere usato spesso dove virtualenvviene utilizzato, ma vorrei stare lontano da esso anche perché penso che venvfaccia anche quello per cui pyenvè stato progettato.

venvcrea 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 installmentre 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 senzasudoin alcune directory che già possiedi, quindi non avrai bisogno delle sudoautorizzazioni 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 venvche ti consente di gestire più ambienti Python. Tuttavia, con pyenvte non è possibile eseguire il rollback delle installazioni delle librerie su un certo stato iniziale e probabilmente avrai bisogno dei adminprivilegi 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.

Sono andato nella pipenvtana del coniglio ( è davvero un buco profondo e scuro ... ) e poiché l'ultima risposta è di oltre 2 anni fa , ho ritenuto utile aggiornare la discussione con gli ultimi sviluppi sull'argomento delle buste virtuali di Python I ho trovato.

NOTA BENE:

Questa risposta NON riguarda il proseguimento del dibattito infuriato sui meriti di pipenv contro venv come soluzioni di inviluppo. Neanche io approvo . Si tratta di PyPA che approva gli standard in conflitto e di come il futuro sviluppo di virtualenv promette di negare di fare una o entrambe le scelte. Mi sono concentrato su questi due strumenti proprio perché sono quelli unti di PyPA .

venv

Come osserva l'OP, venv è uno strumento per virtualizzare gli ambienti. NON una soluzione di terze parti, ma strumento nativo. PyPA approva venv per la creazione di BUSTE VIRTUALI : " Modificato nella versione 3.5: L'uso di venv è ora raccomandato per la creazione di ambienti virtuali ".

pipenv

pipenv - come venv - può essere usato per creare buste virtuali ma anchefunzionalità digestione dei pacchetti roll-in e controllo delle vulnerabilità . Invece di utilizzarerequirements.txt,pipenvoffre la gestione dei pacchetti tramite Pipfile . Dato che PyPA approva pipenv per la GESTIONE DEI PACCHETTI , ciò che sembra implicarepipfileè soppiantarerequirements.txt.

TUTTAVIA : pipenv utilizza virtualenv come strumento per la creazione di buste virtuali, NON venv, che è approvato da PyPA come strumento di riferimento per la creazione di buste virtuali.

Standard contrastanti:

Quindi, se accontentarsi di una soluzione di inviluppo virtuale non fosse abbastanza difficile, ora abbiamo PyPA che approva due diversi strumenti che utilizzano diverse soluzioni di inviluppo virtuale. Il furioso dibattito di Github su venv vs virtualenv che mette in evidenza questo conflitto può essere trovato qui .

Risoluzione del conflitto:

Il dibattito Github a cui si fa riferimento nel link sopra ha orientato lo sviluppo di virtualenv nella direzione di accomodare venv nelle versioni future :

preferisce venv integrato: se il python target ha venv creeremo l'ambiente usando quello (e quindi eseguiremo le operazioni successive su quello per facilitare altre garanzie che offriamo)

Conclusione:

Quindi sembra che ci sarà una certa convergenza futura tra le due soluzioni concorrenti di inviluppo virtuale, ma a partire da ora pipenv - che utilizza virtualenv- varia materialmente da venv.

Dati i problemi che pipenv risolve e il fatto che PyPA abbia dato la sua benedizione, sembra avere un futuro brillante. E se virtualenv realizza gli obiettivi di sviluppo proposti, la scelta di una soluzione di inviluppo virtuale non dovrebbe più essere un caso di pipenv o di venv .

Aggiornamento di aprile 2020

Stavo cercando lo stesso quando mi sono imbattuto in questo post . Penso che questo problema di quale strumento usare sia abbastanza confuso e difficile per i nuovi utenti di Python come me. Questo è direttamente dal sito web PyPA per quanto riguarda pipenv:

Mentre questo tutorial copre il progetto pipenv come uno strumento che si concentra principalmente sulle esigenze dello sviluppo di applicazioni Python piuttosto che sullo sviluppo delle librerie Python, il progetto stesso sta attualmente lavorando attraverso diversi problemi di processo e manutenzione che impediscono la pubblicazione di correzioni di bug e nuove funzionalità ( per tutto il 2019 che passa senza una nuova versione). Ciò significa che a breve termine, pipenv soffre ancora di diverse stranezze e problemi di prestazioni senza una chiara tempistica per la risoluzione di tali problemi.

Sebbene ciò rimanga il caso, è probabile che i manutentori del progetto desiderino indagare su altri strumenti per la gestione delle dipendenze delle applicazioni da utilizzare al posto o insieme a pipenv.

Supponendo che il rilascio di pipenv dell'aprile 2020 proceda come previsto, e anche il rilascio successivo continuerà a funzionare, quindi questo avvertimento sul tutorial verrà rimosso. Se tali versioni non rimangono in pista, il tutorial stesso verrà rimosso e sostituito con una pagina di discussione sulle opzioni di gestione delle dipendenze disponibili.