Conda sostituisce la necessità di virtualenv?

205

Di recente ho scoperto Conda dopo aver avuto problemi con l'installazione di SciPy, in particolare su un'app Heroku che sto sviluppando.

Con Conda crei ambienti, molto simili a quelli di virtualenv . Le mie domande sono:

Se uso Conda sostituirà la necessità di virtualenv? In caso contrario, come posso usare i due insieme? Installo virtualenv in Conda o Conda in virtualenv?
Devo ancora usare pip? In tal caso, sarò ancora in grado di installare pacchetti con pip in un ambiente isolato?

— Kritz
fonte

Se sei interessato ad usare conda e pip su Heroku, vedi ad esempio github.com/faph/conda-pip-buildpack

— faph

Grazie. Ho notato che ci sono molti buildpack conda per Heroku su github. Quali fattori dovrei prendere in considerazione quando decido quale buildpack usare?

— Kritz,

Si noti che sarà comunque necessario utilizzare pip se si desidera installare pacchetti che non sono disponibili direttamente dai server di Continuum.

— ali_m

Sì, ho visto che sono ancora su Django 1.8 (non 1.9). Al momento userò conda dove necessario (scipy e intorpidito) e pip per tutto il resto - ma ancora all'interno di conda.

— Kritz,

Penso che la maggior parte dei builda di Heroku provengano da quello di Kenneth Reitz. Con le persone che le modificano in base alle proprie preferenze. Controlla se includono sia conda che pip support se è quello che ti serve. E se supportano il file environment.yml. Puoi sempre consultare rapidamente il codice buildpack per vedere se ti piace lo script build, ad esempio per vedere come vengono creati esattamente gli ambienti.

— faph,

157

Conda sostituisce virtualenv. Secondo me è meglio. Non è limitato a Python ma può essere utilizzato anche per altre lingue. Nella mia esperienza fornisce un'esperienza molto più fluida, specialmente per i pacchetti scientifici. È stata la prima volta che MayaVi è stato installato correttamente su Mac conda.
Puoi ancora usare pip. In effetti, si condainstalla pipin ogni nuovo ambiente. Conosce i pacchetti installati su pip.

Per esempio:

conda list

elenca tutti i pacchetti installati nel tuo ambiente attuale. I pacchetti installati da Conda si presentano così:

sphinx_rtd_theme          0.1.7                    py35_0    defaults

e quelli installati tramite piphanno il <pip>marker:

wxpython-common           3.0.0.0                   <pip>

— Mike Müller
fonte

8

C'è qualche aspetto negativo nell'uso di pip in un ambiente Anaconda? C'è mai un caso in cui vorresti usare pip anche se un pacchetto era disponibile tramite Conda?

— clifgray,

La differenza è trattino vs trattino basso? Cosa succede se il nome del pacchetto non ha nessuno dei due? Come differenziare allora?

— Tom Hale,

1

Il trattino basso o il trattino fa parte del nome del pacchetto. Questo non ha nulla a che fare con pip o conda. Gli <pip>spettacoli che è stato installato con pip altrimenti viene installato con Conda.

— Mike Müller,

4

C'è un grosso avvertimento con "conda sa dei pacchetti installati su pip". Da quanto ho capito, all'interno di un ambiente conda, pip agisce in modo indipendente, quindi conda non può disinstallare i pacchetti installati pip per esempio

— information_interchange

1

@clifgray - i pacchetti pip e conda che hanno librerie condivise native possono installare versioni binarie incompatibili di quelle che inizieranno a causare ogni sorta di guasti al mondo nativo (sigsegv-s, ecc.) difficili da eseguire il debug per qualcuno che non è al passo con un debugger C. Lo stesso vale per i pacchetti solo per Python, solo che sono facili da capire.

— Bobah

61

La risposta breve è, hai solo bisogno di conda.

Conda combina efficacemente le funzionalità di pip e virtualenv in un unico pacchetto, quindi non è necessario virtualenv se si utilizza conda.
Rimarrai sorpreso da quanti pacchetti conda supporta. Se non è abbastanza, puoi usare pip in conda.

Ecco un link alla pagina conda che confronta conda, pip e virtualenv:

https://docs.conda.io/projects/conda/en/latest/commands.html#conda-vs-pip-vs-virtualenv-commands .

— Fisico pazzo
fonte

34

Ambienti virtuali e pip

Aggiungerò che creare e rimuovere ambienti conda è semplice con Anaconda.

> conda create --name <envname> python=<version> <optional dependencies>

> conda remove --name <envname> --all

In un ambiente attivato , installare i pacchetti tramite condao pip:

(envname)> conda install <package>

(envname)> pip install <package>

Questi ambienti sono fortemente legati alla gestione dei pacchetti simili a pip di conda , quindi è semplice creare ambienti e installare pacchetti Python e non Python.

Jupyter

Inoltre, l' installazioneipykernel in un ambiente aggiunge un nuovo elenco nel menu a discesa Kernels dei notebook Jupyter, estendendo gli ambienti riproducibili ai notebook. A partire da Anaconda 4.1, sono state aggiunte nbextension , aggiungendo più facilmente le estensioni ai notebook.

Affidabilità

Nella mia esperienza, conda è più veloce e più affidabile nell'installazione di librerie di grandi dimensioni come numpye pandas. Inoltre, se desideri trasferire il tuo stato preservato di un ambiente, puoi farlo condividendo o clonando un ambiente.

— pylang
fonte

18

L'installazione di Conda ti consentirà di creare e rimuovere gli ambienti python come desideri, offrendo quindi le stesse funzionalità di virtualenv .

Nel caso di entrambe le distribuzioni, saresti in grado di creare un albero di filesystem isolato, dove puoi installare e rimuovere i pacchetti python (probabilmente, con pip) come desideri. Il che potrebbe tornare utile se vuoi avere versioni diverse della stessa libreria per diversi casi d'uso o vuoi solo provare un po 'di distribuzione e rimuoverlo in seguito conservando il tuo spazio su disco.

differenze:

Accordo di licenza Mentre virtualenv rientra nella maggior parte della licenza MIT liberale , Conda utilizza la licenza BSD a 3 clausole.

Conda offre il proprio sistema di controllo dei pacchetti. Questo sistema di controllo dei pacchetti fornisce spesso versioni precompilate (per i sistemi più diffusi) dei più diffusi software non Python, il che può facilmente facilitare il funzionamento di alcuni pacchetti di machine learning. Vale a dire non è necessario compilare codice C / C ++ ottimizzato per il proprio sistema. Sebbene sia un grande sollievo per la maggior parte di noi, potrebbe influire sulle prestazioni di tali librerie.

A differenza di virtualenv, Conda duplica alcune librerie di sistema almeno sul sistema Linux. Queste librerie possono non essere sincronizzate portando a comportamenti incoerenti dei programmi.

Verdetto:

Conda è eccezionale e dovrebbe essere la tua scelta predefinita mentre inizi la tua strada con l'apprendimento automatico. Ti farà risparmiare un po 'di tempo giocando con gcc e numerosi pacchetti. Tuttavia, Conda non sostituisce virtualenv. Presenta qualche complessità aggiuntiva che potrebbe non essere sempre desiderata. Viene fornito con una licenza diversa. Potresti voler evitare l'uso di conda su ambienti distribuiti o su hardware HPC.

— y.selivonchyk
fonte

2

ti dispiace elaborare un po 'di più perché "potresti voler evitare l'uso di conda su ambienti distribuiti o su hardware HPC"? @ y.selivonchyk

— Oliver Hu

1

Non sono d'accordo con alcune di queste conclusioni. "Comportamento incoerente del programma" è il risultato della non corretta configurazione dei programmi per l'utilizzo del condasoftware e delle librerie installati. E in HPC, condaè preferibile in molti casi, infatti viene utilizzato dagli amministratori HPC per sostituire cose come i modulesistemi. Consente il software installato dall'utente e un maggiore isolamento del software, due grandi problemi su HPC. L'unica avvertenza che ho riscontrato è che molti filesystem HPC hanno limiti rigidi al numero di file in una directory e conda crea molti migliaia di file.

— user5359531

9

Uso entrambi e (a partire da gennaio 2020) presentano alcune differenze superficiali che si prestano a usi diversi per me. Per impostazione predefinita, Conda preferisce gestire un elenco di ambienti in una posizione centrale, mentre virtualenv crea una cartella nella directory corrente. Il primo (centralizzato) ha senso se, ad esempio, stai facendo l'apprendimento automatico e hai solo un paio di ampi ambienti che usi in molti progetti e vuoi saltarci dentro da qualsiasi luogo. Quest'ultimo (per cartella di progetto) ha senso se stai facendo piccoli progetti una tantum che hanno insiemi di requisiti di lib completamente diversi che appartengono realmente al progetto stesso.

L'ambiente vuoto creato da Conda è di circa 122 MB, mentre quello di virtualenv è di circa 12 MB, quindi questo è un altro motivo per cui potresti preferire non disperdere ambienti Conda ovunque.

Infine, un'altra indicazione superficiale che Conda preferisce i suoi env centralizzati è che (di nuovo, per impostazione predefinita) se crei un conda env nella tua cartella del progetto e lo attivi, il prefisso del nome che appare nella tua shell è l'assoluto (troppo lungo) percorso della cartella. Puoi risolverlo dandogli un nome, ma virtualenv fa la cosa giusta di default.

Mi aspetto che queste informazioni diventino rapidamente vecchie quando i due gestori di pacchetti si contendono il dominio, ma questi sono i compromessi di oggi :)

— Pat Niemeyer
fonte

Buona spiegazione Hai delle difficoltà ad usarli entrambi? Hai mai usato pipenv?

— Mikhail_Sam,

8

Un'altra nuova opzione e il mio attuale metodo preferito per rendere operativo un ambiente è Pipenv

Attualmente è lo strumento di packaging Python ufficialmente raccomandato da Python.org

— Kritz
fonte

1

Questo ha spinto "eh? Cos'è pipenv?", Che mi ha portato a reddit.com/r/Python/comments/8jd6aq/… e sedimental.org/the_packaging_gradient.html . Non so ancora cosa usare ma almeno sono meglio informato. Penso.

— Matt Wilkie,

Dopo aver visto l'introduzione e aver letto rapidamente l'introduzione, pipenv sembra non essere in grado di gestire le versioni di Python ...

— Carles Alcolea,

@CarlesAlcolea pipenv può specificare anche le varie versioni: pipenv --twoper Python2 e pipenv - three per python3

— Kurian Benoy,

3

Sì, condaè molto più facile da installare di virtualenve sostituisce praticamente quest'ultimo.

— Liang Huang
fonte

6

Perché Anaconda fornisce istruzioni per l'installazione di un ambiente virtuale se li sostituisce?

— Jmh

1

@jmh Anaconda non sostituisce gli ambienti virtuali, sostituisce lo strumento di gestione dell'ambiente virtuale specifico di Python virtualenvcon uno strumento di gestione dell'ambiente virtuale più generale conda. Inoltre, Anaconda è solo una distribuzione Python + che include lo strumento Conda; la domanda (e la risposta) riguarda solo Conda.

— Merv,

3

Questa risposta non aggiunge nulla oltre alle risposte che sono arrivate anni prima.

— Merv,

1

Lavoro in azienda, dietro vari firewall con macchine su cui non ho accesso come amministratore

Nella mia esperienza limitata con Python (2 anni) ho incontrato alcune librerie (JayDeBeApi, sasl) che durante l'installazione tramite pip generavano errori di dipendenza C ++: è richiesto Microsoft Visual C ++ 14.0. Scarica con "Microsoft Visual C ++ Build Tools": http://landinghub.visualstudio.com/visual-cpp-build-tools

questi sono stati installati bene con conda, quindi da quei giorni ho iniziato a lavorare con conda env. tuttavia non è facile impedire a conda di installare la dipendenza all'interno di c.programfiles dove non ho accesso in scrittura.

— Rohit Arora
fonte