Jakie są pułapki korzystania wyłącznie z PIP w środowisku CONDA?
tło
Oficjalna dokumentacja i ten blog na tej samej stronie - zalecamy zainstalowanie jak największej liczby wymagań, aconda
następnie użycie pip. Najwyraźniej dzieje się tak, ponieważ conda
nie będzie świadomy jakichkolwiek zmian w zależnościach wprowadzonych przez pip
i dlatego nie będzie w stanie poprawnie rozwiązać zależności.
Pytanie
Teraz, jeśli ktoś używa pip
i nie instaluje niczego z programem conda
, wydaje się rozsądnym oczekiwać, conda
że nie trzeba być świadomym żadnych zmian wprowadzonych przez pip
- ponieważ w conda
praktyce staje się zwykłym narzędziem do izolowania zależności i zarządzania wersjami. Jest to jednak sprzeczne z oficjalnymi zaleceniami, ponieważ NIE można zainstalować jak największej liczby wymagań zconda
.
Pozostaje więc pytanie: czy są jakieś znane wady wynikające z używania wyłączniepip
w conda
środowisku?
Podobne tematy
Podobny temat został tutaj nieco poruszony , ale nie obejmuje przypadku używania wyłącznie pip
w conda
środowisku. Ja też tu byłem:
- Konkretne powody, dla których warto preferować pip i conda podczas instalowania pakietów Pythona
- Jaka jest różnica między pip i conda?
- Używanie potoku do instalowania pakietów w środowisku Anaconda
Odpowiedzi
Nie jestem pewien, czy można udzielić wyczerpującej odpowiedzi na ten temat, ale niektóre z głównych rzeczy, które przychodzą na myśl, to:
Brak głębokiej obsługi rozwiązywania zależności innych niż Python . Chociaż z czasem pojawiło się więcej kół, które obejmują zasoby inne niż Python, nie jest to nawet bliskie pokryciu, które zapewnia Conda, będąc ogólnym menedżerem pakietów, a nie specyficznym dla Pythona. Dla każdego, kto zajmuje się przetwarzaniem interoperacyjnym (np.
reticulate
), Oczekiwałbym, że Conda będzie faworyzowana.Zoptymalizowane biblioteki . Trochę to związane z pierwszym punktem, ale zespół Anaconda podjął wysiłek stworzenia zoptymalizowanych wersji pakietów (np. MKL dla
numpy
). Nie jestem pewien, czy odpowiednik jest dostępny przez PyPI. 1Nieekonomiczna nadmiarowość w różnych środowiskach . Conda używa hardlinkowania, gdy pakiety i środowiska są na tym samym wolumenie, i obsługuje miękkie linkowanie do obejmowania woluminów. Pomaga to zminimalizować replikowanie pakietów zainstalowanych w wielu środowiskach.
Komplikuje eksport . Podczas eksportu (
conda env export
) Conda nie odbiera wszystkichpip
zainstalowanych pakietów - tylko te, które pochodzą z PyPI. Oznacza to, że przegapi rzeczy zainstalowane z GitHub itp. Jeśli ktoś skorzystał z trasy obejmującej tylko pip, myślę, że bardziej niezawodną strategią eksportową byłoby użyciepip freeze > requirements.txt
, a następnie utworzenie YAML-a takiego jakchannels: - defaults dependencies: - python=3.8 # specify the version - pip - pip: - -r requirements.txt
za pomocą których można odtworzyć środowisko.
Mimo wszystko mogłem sobie wyobrazić, że nic z tych rzeczy nie ma znaczenia dla niektórych ludzi (większość z nich to udogodnienia), zwłaszcza tych, którzy mają tendencję do pracy wyłącznie w Pythonie. W takich przypadkach nie widzę jednak powodu, dla którego nie można by po prostu całkowicie zrezygnować z Conda i użyć menedżera środowiska wirtualnego specyficznego dla Pythona.
[1] Niech ktoś mnie poprawi, jeśli wiesz inaczej.