Jakie są pułapki korzystania wyłącznie z PIP w środowisku CONDA?

Dec 02 2020

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ż condanie będzie świadomy jakichkolwiek zmian w zależnościach wprowadzonych przez pipi dlatego nie będzie w stanie poprawnie rozwiązać zależności.

Pytanie

Teraz, jeśli ktoś używa pipi nie instaluje niczego z programem conda, wydaje się rozsądnym oczekiwać, condaże nie trzeba być świadomym żadnych zmian wprowadzonych przez pip- ponieważ w condapraktyce 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 pipw 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

2 merv Dec 02 2020 at 03:49

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:

  1. 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.

  2. 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. 1

  3. Nieekonomiczna 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.

  4. Komplikuje eksport . Podczas eksportu ( conda env export) Conda nie odbiera wszystkich pipzainstalowanych 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życie pip freeze > requirements.txt, a następnie utworzenie YAML-a takiego jak

    channels:
      - 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.