Conda remplace-t-il le besoin de virtualenv?

205

J'ai récemment découvert Conda après avoir eu du mal à installer SciPy, en particulier sur une application Heroku que je développe.

Avec Conda, vous créez des environnements très similaires à ce que fait virtualenv . Mes questions sont:

  1. Si j'utilise Conda, cela remplacera-t-il le besoin de virtualenv? Sinon, comment utiliser les deux ensemble? Dois-je installer virtualenv dans Conda ou Conda dans virtualenv?
  2. Dois-je toujours utiliser pip? Si oui, pourrai-je toujours installer des packages avec pip dans un environnement isolé?
python scipy virtualenv anaconda conda Kritz
la source
Si vous êtes intéressé à utiliser conda et pip sur Heroku, voir par exemple github.com/faph/conda-pip-buildpack
faph
Merci. J'ai remarqué qu'il existe un certain nombre de packs de construction de conda pour Heroku sur github. Quels facteurs dois-je prendre en compte pour décider quel buildpack utiliser?
Kritz
Notez que vous devrez toujours utiliser pip si vous souhaitez installer des packages qui ne sont pas disponibles directement à partir des serveurs de Continuum.
ali_m
Oui, j'ai vu qu'ils sont toujours sur Django 1.8 (pas 1.9). Pour le moment, j'utiliserai la conda si nécessaire (scipy et numpy) et pip pour tout le reste - mais toujours dans la conda.
Kritz
La plupart des packs de construction conda Heroku proviennent de celui de Kenneth Reitz, je pense. Avec des gens qui les ajustent en fonction de leurs préférences. Vérifiez simplement s'ils incluent à la fois le support conda et pip si c'est ce dont vous avez besoin. Et s'ils prennent en charge le fichier environment.yml. Vous pouvez toujours parcourir rapidement le code du buildpack pour voir si vous aimez le script de build, par exemple pour voir exactement comment les environnements sont créés.
faph

Réponses:

157

  1. Conda remplace virtualenv. À mon avis, c'est mieux. Il n'est pas limité à Python mais peut également être utilisé pour d'autres langages. D'après mon expérience, cela offre une expérience beaucoup plus fluide, en particulier pour les packages scientifiques. La première fois que j'ai installé MayaVi correctement sur Mac, c'était avec conda.

  2. Vous pouvez toujours utiliser pip. En fait, condas'installe pipdans chaque nouvel environnement. Il connaît les packages installés par pip.

Par exemple:

conda list

répertorie tous les packages installés dans votre environnement actuel. Les packages installés par Conda apparaissent comme ceci:

sphinx_rtd_theme          0.1.7                    py35_0    defaults

et ceux installés via pipont le <pip>marqueur:

wxpython-common           3.0.0.0                   <pip>
Mike Müller
la source
8
Y a-t-il un inconvénient à utiliser pip dans un environnement Anaconda? Y a-t-il jamais un cas où vous voudriez utiliser pip même si un paquet était disponible via Conda?
clifgray
La différence est un trait d'union vs un trait de soulignement? Que faire si le nom du package n'a ni l'un ni l'autre? Comment se différencier alors?
Tom Hale
1
Le trait de soulignement ou le tiret fait partie du nom du package. Cela n'a rien à voir avec pip ou conda. Le <pip>montre qu'il a été installé avec pip sinon il est installé avec conda.
Mike Müller
4
Il y a une grosse mise en garde avec "conda connaît les packages installés par pip". D'après ma compréhension, à l'intérieur d'un environnement conda, pip agit indépendamment, donc conda ne peut pas désinstaller les packages installés par pip par exemple
information_interchange
1
@clifgray - les packages pip et conda ayant des bibliothèques partagées natives peuvent installer des versions binaires incompatibles de celles qui commenceront à provoquer toutes sortes de défaillances du monde natif (sigsegv-s, etc.) difficiles à déboguer pour quelqu'un qui n'est pas au courant avec un débogueur C. Idem pour les packages python uniquement, juste que ceux-ci sont faciles à comprendre.
bobah
61

En bref, vous n'avez besoin que de conda.

  1. Conda combine efficacement les fonctionnalités de pip et virtualenv dans un seul paquet, vous n'avez donc pas besoin de virtualenv si vous utilisez conda.

  2. Vous seriez surpris du nombre de packages pris en charge par conda. Si cela ne suffit pas, vous pouvez utiliser pip sous conda.

Voici un lien vers la page conda comparant conda, pip et virtualenv:

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

Physicien fou
la source
34

Environnements virtuels et pip

J'ajouterai que créer et supprimer des environnements conda est simple avec Anaconda.

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

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

Dans un environnement activé , installez les packages via condaou pip:

(envname)> conda install <package>

(envname)> pip install <package>

Ces environnements sont fortement liés à la gestion des packages de type pip de conda , il est donc simple de créer des environnements et d'installer des packages Python et non-Python.

Jupyter

De plus, l' installationipykernel dans un environnement ajoute une nouvelle liste dans le menu déroulant Kernels des blocs-notes Jupyter, étendant les environnements reproductibles aux blocs-notes. Depuis Anaconda 4.1, nbextensions a été ajoutée , ajoutant plus facilement des extensions aux blocs-notes.

Fiabilité

D'après mon expérience, conda est plus rapide et plus fiable pour installer de grandes bibliothèques telles que numpyet pandas. De plus, si vous souhaitez transférer votre état préservé d'un environnement, vous pouvez le faire en partageant ou clonant un env.

pylang
la source
18

L'installation de Conda vous permettra de créer et de supprimer des environnements python comme vous le souhaitez, vous offrant ainsi les mêmes fonctionnalités que virtualenv .

Dans le cas des deux distributions, vous seriez en mesure de créer une arborescence de systèmes de fichiers isolée, où vous pouvez installer et supprimer des packages python (probablement, avec pip) comme vous le souhaitez. Ce qui pourrait être utile si vous souhaitez avoir différentes versions de la même bibliothèque pour différents cas d'utilisation ou si vous voulez simplement essayer une distribution et la supprimer ensuite en conservant votre espace disque.

Différences:

Accord de licence. Alors que virtualenv relève de la licence MIT la plus libérale , Conda utilise une licence BSD à 3 clauses.

Conda vous fournit son propre système de contrôle des packages. Ce système de contrôle de package fournit souvent des versions précompilées (pour les systèmes les plus populaires) de logiciels non python populaires, ce qui peut facilement permettre à certains packages d'apprentissage automatique de fonctionner. À savoir, vous n'avez pas à compiler du code C / C ++ optimisé pour votre système. Bien que ce soit un grand soulagement pour la plupart d'entre nous, cela pourrait affecter les performances de ces bibliothèques.

Contrairement à virtualenv, Conda duplique certaines bibliothèques système au moins sur le système Linux. Ces bibliothèques peuvent se désynchroniser et entraîner un comportement incohérent de vos programmes.

Verdict:

Conda est génial et devrait être votre choix par défaut lorsque vous commencez votre chemin avec l'apprentissage automatique. Cela vous fera gagner du temps en jouant avec gcc et de nombreux packages. Pourtant, Conda ne remplace pas virtualenv. Il introduit une complexité supplémentaire qui pourrait ne pas toujours être souhaitée. Il est sous licence différente. Vous voudrez peut-être éviter d'utiliser conda dans des environnements distribués ou sur du matériel HPC.

y.selivonchyk
la source
2
l'esprit d'élaborer un peu plus pourquoi "vous voudrez peut-être éviter d'utiliser conda sur des environnements distribués ou sur du matériel HPC"? @ y.selivonchyk
Oliver Hu
1
Je ne suis pas d'accord avec certaines de ces conclusions. «Comportement incohérent du programme» est le résultat d'une configuration incorrecte de vos programmes pour utiliser le condalogiciel et les bibliothèques installés. Et dans HPC, condaest préférable dans de nombreux cas, en fait, il est utilisé par les administrateurs HPC pour remplacer des choses comme les modulesystèmes. Il permet aux logiciels installés par les utilisateurs et une meilleure isolation des logiciels, deux gros problèmes sur HPC. La seule mise en garde que j'ai rencontrée est que de nombreux systèmes de fichiers HPC ont des limites strictes sur le nombre de fichiers dans un répertoire, et conda crée plusieurs milliers de fichiers.
user5359531
9

J'utilise les deux et (à partir de janvier 2020), ils ont des différences superficielles qui se prêtent à des usages différents pour moi. Par défaut, Conda préfère gérer une liste d'environnements pour vous dans un emplacement central, tandis que virtualenv crée un dossier dans le répertoire actuel. Le premier (centralisé) est logique si vous effectuez par exemple un apprentissage automatique et que vous n'avez que quelques environnements généraux que vous utilisez dans de nombreux projets et que vous souhaitez y accéder de n'importe où. Ce dernier (par dossier de projet) a du sens si vous faites de petits projets ponctuels qui ont des ensembles d'exigences de bibliothèque complètement différents qui appartiennent vraiment davantage au projet lui-même.

L'environnement vide créé par Conda est d'environ 122 Mo, tandis que celui de virtualenv est d'environ 12 Mo. C'est donc une autre raison pour laquelle vous préférerez peut-être ne pas disperser les environnements Conda partout.

Enfin, une autre indication superficielle que Conda préfère ses envs centralisés est que (encore une fois, par défaut) si vous créez un env Conda dans votre propre dossier de projet et l'activez le préfixe de nom qui apparaît dans votre shell est l'absolu (beaucoup trop long) chemin d'accès au dossier. Vous pouvez résoudre ce problème en lui donnant un nom, mais virtualenv fait la bonne chose par défaut.

Je m'attends à ce que ces informations deviennent rapidement obsolètes car les deux gestionnaires de packages se disputent la domination, mais ce sont les compromis à compter d'aujourd'hui :)

Pat Niemeyer
la source
Bonne explication! Avez-vous des difficultés à utiliser les deux? Avez-vous déjà utilisé pipenv?
Mikhail_Sam
8

Pipenv est une autre nouvelle option et ma méthode préférée actuelle pour obtenir un environnement opérationnel .

C'est actuellement l'outil de packaging Python officiellement recommandé de Python.org

Kritz
la source
1
Cela a incité "hein? Qu'est-ce que pipenv?", Ce qui m'a conduit à reddit.com/r/Python/comments/8jd6aq/… et sedimental.org/the_packaging_gradient.html . Je ne sais toujours pas quoi utiliser mais au moins je suis mieux informé. Je pense.
matt wilkie
Après avoir regardé l'intro et lu rapidement l'introduction, pipenv semble incapable de gérer les versions de Python ...
Carles Alcolea
@CarlesAlcolea pipenv peut également spécifier les différentes versions par: pipenv --twopour Python2 et pipenv - trois pour python3
Kurian Benoy
3

Oui, condaest beaucoup plus facile à installer que virtualenv, et remplace à peu près ce dernier.

Liang Huang
la source
6
Pourquoi Anaconda fournit-il des instructions pour installer un environnement virtuel s'il les remplace?
jmh
1
@jmh Anaconda ne remplace pas les environnements virtuels, il remplace l'outil de gestion de l'environnement virtuel spécifique à Python virtualenvpar un outil de gestion de l'environnement virtuel plus général conda. De plus, Anaconda est juste une distribution Python + qui inclut l'outil Conda; la question (et la réponse) ne concerne que Conda.
merv
3
Cette réponse n'ajoute rien au-delà des réponses qui ont précédé des années.
merv
1

Je travaille en entreprise, derrière plusieurs pare-feu avec une machine sur laquelle je n'ai pas d'accès administrateur

Dans mon expérience limitée avec python (2 ans), je suis tombé sur quelques bibliothèques (JayDeBeApi, sasl) qui lors de l'installation via pip ont jeté une erreur d'erreurs de dépendance C ++: Microsoft Visual C ++ 14.0 est requis. Obtenez-le avec "Microsoft Visual C ++ Build Tools": http://landinghub.visualstudio.com/visual-cpp-build-tools

ceux-ci ont bien installé avec conda, donc depuis ces jours, j'ai commencé à travailler avec conda env. Cependant, il n'est pas facile d'empêcher conda d'installer des dépendances à l'intérieur de c.programfiles où je n'ai pas accès en écriture.

rohit arora
la source