Czy Conda zastępuje potrzebę virtualenv?


205

Niedawno odkryłem Condę po tym, jak miałem problemy z instalacją SciPy, szczególnie w aplikacji Heroku, którą opracowuję.

Dzięki Conda tworzysz środowiska, bardzo podobne do tego, co robi virtualenv . Moje pytania to:

  1. Jeśli użyję Condy, czy zastąpi ona potrzebę virtualenv? Jeśli nie, w jaki sposób korzystać z nich razem? Czy instaluję virtualenv w Conda, czy Conda w virtualenv?
  2. Czy nadal muszę używać pipa? Jeśli tak, czy nadal będę mógł instalować pakiety z pipem w izolowanym środowisku?

Jeśli jesteś zainteresowany używaniem conda i pip na Heroku, zobacz na przykład github.com/faph/conda-pip-buildpack
faph

Dzięki. Zauważyłem, że na github jest wiele pakietów buildów dla Heroku. Jakie czynniki należy wziąć pod uwagę przy podejmowaniu decyzji, którego pakietu należy użyć?
Kritz,

Pamiętaj, że nadal będziesz musiał użyć pip, jeśli chcesz zainstalować pakiety, które nie są dostępne bezpośrednio z serwerów Continuum.
ali_m

Tak, widziałem, że wciąż są na Django 1.8 (nie 1.9). W tej chwili będę używać conda w razie potrzeby (scipy i numpy) i pip do wszystkiego innego - ale nadal w conda.
Kritz

Myślę, że większość pakietów buildów Heroku pochodzi od Kennetha Reitza. Ludzie dostosowują je do swoich preferencji. Po prostu sprawdź, czy obejmują one obsługę conda i pip, jeśli tego potrzebujesz. A jeśli obsługują plik environment.yml. Zawsze możesz szybko przejrzeć kod kompilacji, aby zobaczyć, czy podoba ci się skrypt kompilacji, na przykład, aby zobaczyć, jak dokładnie tworzone są środowiska.
faph

Odpowiedzi:


157
  1. Conda zastępuje virtualenv. Moim zdaniem jest lepiej. Nie jest ograniczony do Pythona, ale można go również używać w innych językach. Z mojego doświadczenia wynika, że ​​zapewnia znacznie płynniejsze działanie, szczególnie w przypadku pakietów naukowych. Pierwszy raz poprawnie zainstalowałem MayaVi na komputerze Mac conda.

  2. Nadal możesz używać pip. W rzeczywistości condainstaluje się pipw każdym nowym środowisku. Wie o pakietach instalowanych przez pip.

Na przykład:

conda list

wyświetla listę wszystkich zainstalowanych pakietów w bieżącym środowisku. Pakiety zainstalowane Conda pokazują się tak:

sphinx_rtd_theme          0.1.7                    py35_0    defaults

a te zainstalowane przez pipmają <pip>znacznik:

wxpython-common           3.0.0.0                   <pip>

8
Czy korzystanie z pip w środowisku Anaconda ma jakieś negatywne skutki? Czy zdarza się, że chciałbyś użyć pip, nawet jeśli pakiet był dostępny przez Condę?
clifgray

Różnica jest łącznikiem vs podkreślenie? Co jeśli nazwa pakietu nie ma? Jak zatem odróżnić?
Tom Hale

1
Znak podkreślenia lub łącznik jest częścią nazwy pakietu. To nie ma nic wspólnego z pipem lub condą. Do <pip>pokazuje, że został on zainstalowany z pip inaczej jest on zainstalowany z Conda.
Mike Müller,

4
Jest duże zastrzeżenie z „conda wie o pakietach instalowanych przez pip”. Z mojego zrozumienia, w env conda, pip działa niezależnie, więc conda nie może na przykład odinstalować zainstalowanych pakietów pip
information_interchange

1
@clifgray - pakiety pip i conda z natywnymi bibliotekami współdzielonymi mogą instalować binarnie niekompatybilne wersje tych, które zaczną powodować różnego rodzaju awarie rodzimego świata (sigsegv-s itp.) trudne do debugowania dla kogoś, kto nie jest zbyt szybki z debuggerem C. To samo dotyczy pakietów tylko do Pythona, tyle że łatwo je zrozumieć.
bobah


34

Środowiska wirtualne i pip

Dodam, że tworzenie i usuwanie środowisk conda jest proste dzięki Anaconda.

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

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

W aktywowanym środowisku zainstaluj pakiety za pomocą condalub pip:

(envname)> conda install <package>

(envname)> pip install <package>

Środowiska te są ściśle powiązane z zarządzaniem pakietami typu conda , więc tworzenie środowisk i instalowanie zarówno pakietów Python, jak i innych niż Python jest proste.


Jupyter

Ponadto instalacjaipykernel w środowisku dodaje nową listę w menu rozwijanym Jądra notebooków Jupyter, rozszerzając odtwarzalne środowiska na notebooki. Począwszy od wersji Anaconda 4.1, dodawano rozszerzenia n , ułatwiając dodawanie rozszerzeń do notebooków.

Niezawodność

Z mojego doświadczenia wynika, że ​​conda jest szybsza i bardziej niezawodna w instalowaniu dużych bibliotek, takich jak numpyi pandas. Ponadto, jeśli chcesz przenieść swój zachowany stan środowiska, możesz to zrobić, dzieląc się lub klonując env.


18

Zainstalowanie Conda pozwoli ci tworzyć i usuwać środowiska Pythona według własnego uznania, zapewniając tym samym taką samą funkcjonalność jak virtualenv .

W przypadku obu dystrybucji można utworzyć izolowane drzewo systemu plików, w którym można instalować i usuwać pakiety Pythona (prawdopodobnie za pomocą pipa) według własnego uznania. Co może się przydać, jeśli chcesz mieć różne wersje tej samej biblioteki dla różnych przypadków użycia lub po prostu chcesz wypróbować dystrybucję i usunąć ją później, oszczędzając miejsce na dysku.

Różnice:

Umowa licencyjna. Podczas gdy virtualenv jest objęty najbardziej liberalną licencją MIT , Conda stosuje 3 klauzulę licencji BSD.

Conda zapewnia własny system kontroli pakietów. Ten system kontroli pakietów często udostępnia wstępnie skompilowane wersje (dla najpopularniejszych systemów) popularnego oprogramowania niebędącego pythonem, co może ułatwić uruchomienie niektórych pakietów uczenia maszynowego. Mianowicie nie musisz kompilować zoptymalizowanego kodu C / C ++ dla swojego systemu. Chociaż dla większości z nas stanowi to wielką ulgę, może mieć wpływ na wydajność takich bibliotek.

W przeciwieństwie do virtualenv, Conda powiela niektóre biblioteki systemowe przynajmniej w systemie Linux. Te biblioteki mogą się zsynchronizować, co prowadzi do niespójnego działania programów.

Werdykt:

Conda jest świetna i powinna być Twoim domyślnym wyborem na początku nauki maszynowej. Zaoszczędzisz trochę czasu na bałaganie z gcc i licznymi pakietami. Jednak Conda nie zastępuje virtualenv. Wprowadza dodatkową złożoność, która nie zawsze może być pożądana. Jest objęty inną licencją. Możesz uniknąć używania conda w środowiskach rozproszonych lub na sprzęcie HPC.


2
Zastanów się nad tym, dlaczego „możesz chcieć uniknąć używania conda w środowiskach rozproszonych lub na sprzęcie HPC”? @ y.selivonchyk
Oliver Hu

1
Nie zgadzam się z niektórymi z tych wniosków. „Niespójne zachowanie programu” jest wynikiem niewłaściwej konfiguracji programów do korzystania z condazainstalowanego oprogramowania i bibliotek. A w HPC condajest preferowany w wielu przypadkach, w rzeczywistości jest używany przez administratorów HPC do zastępowania rzeczy takich jak modulesystemy. Pozwala na zainstalowanie oprogramowania przez użytkownika i lepszą izolację oprogramowania, dwa duże problemy na HPC. Jedynym zastrzeżeniem, jakie odczuwam, jest to, że wiele systemów plików HPC ma twarde ograniczenia liczby plików w katalogu, a conda tworzy wiele 1000 plików.
user5359531

9

Używam obu i (od stycznia 2020 r.) Mają one pewne powierzchowne różnice, które nadają mi się do różnych zastosowań. przez domyślnie Conda woli zarządzać listę środowisk dla Ciebie w centralnej lokalizacji, natomiast virtualenv sprawia folder w bieżącym katalogu. Ten pierwszy (scentralizowany) ma sens, jeśli np. Uczysz się maszynowego uczenia się i masz tylko kilka szerokich środowisk, z których korzystasz w wielu projektach i chcesz wskoczyć do nich z dowolnego miejsca. Ten drugi (na folder projektu) ma sens, jeśli wykonujesz małe jednorazowe projekty, które mają zupełnie inne zestawy wymagań lib, które tak naprawdę należą bardziej do samego projektu.

Puste środowisko, które tworzy Conda, wynosi około 122 MB, podczas gdy wirtualne środowisko ma około 12 MB, więc to kolejny powód, dla którego wolisz nie rozpraszać środowisk Conda wszędzie.

Wreszcie, kolejną powierzchowną wskazówką, że Conda woli scentralizowane środowisko, jest (ponownie, domyślnie), jeśli utworzysz środowisko Conda we własnym folderze projektu i aktywujesz go, prefiks nazwy pojawiający się w twojej powłoce jest (zdecydowanie za długi) absolutem ścieżka do folderu. Możesz to naprawić, nadając mu nazwę, ale virtualenv domyślnie robi to dobrze.

Oczekuję, że te informacje szybko się zestarzeją, gdy dwóch menedżerów pakietów będzie walczyć o dominację, ale są to kompromisy na dziś :)


Dobre wytłumaczenie! Czy masz jakieś trudności z korzystaniem z nich obu? Czy kiedykolwiek używałeś pipenv?
Mikhail_Sam

8

Inną nową opcją i moją obecnie preferowaną metodą uruchomienia środowiska jest Pipenv

Jest to obecnie oficjalnie zalecane narzędzie do pakowania Python z Python.org


1
To skłoniło „eh? What's pipenv?”, Co doprowadziło mnie do reddit.com/r/Python/comments/8jd6aq/… i sedimental.org/the_packaging_gradient.html . Nadal nie wiem, czego użyć, ale przynajmniej jestem lepiej poinformowany. Myślę.
matt wilkie

Po obejrzeniu wstępu i szybkim przeczytaniu wprowadzenia pipenv wydaje się nie być w stanie zarządzać wersjami Pythona ...
Carles Alcolea

@CarlesAlcolea pipenv może również określać różne wersje przez: pipenv --twodla Python2 i pipenv - trzy dla python3
Kurian Benoy

3

Tak, condajest o wiele łatwiejszy do zainstalowania virtualenvi prawie zastępuje ten drugi.


6
Dlaczego Anaconda udostępnia instrukcje instalacji środowiska wirtualnego, jeśli je zastępuje?
jmh

1
@ jmh Anaconda nie zastępuje środowisk wirtualnych, zastępuje specyficzne dla Pythona narzędzie do zarządzania środowiskiem wirtualnym virtualenvbardziej ogólnym narzędziem do zarządzania środowiskiem wirtualnym conda. Anaconda to także dystrybucja Python +, która zawiera narzędzie Conda; pytanie (i odpowiedź) dotyczy tylko Condy.
mer

3
Ta odpowiedź nie dodaje niczego poza odpowiedziami sprzed lat.
mer

1

Pracuję w firmie, za kilkoma zaporami ogniowymi z maszyną, na której nie mam dostępu administratora

Z mojego ograniczonego doświadczenia w Pythonie (2 lata) natknąłem się na kilka bibliotek (JayDeBeApi, sasl), które podczas instalacji przez pip zgłosiły błąd błędów zależności C ++: wymagany jest Microsoft Visual C ++ 14.0. Pobierz za pomocą „Microsoft Visual C ++ Build Tools”: http://landinghub.visualstudio.com/visual-cpp-build-tools

te zainstalowane dobrze z conda, dlatego od tamtych czasów zacząłem pracować z conda env. jednak nie jest łatwo powstrzymać conda przed instalowaniem zależności w c. programogramach, w których nie mam dostępu do zapisu.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.