Pakiety Python są często hostowane w repozytoriach wielu dystrybucji. Po przeczytaniu tego samouczka, a konkretnie sekcji zatytułowanej „Czy naprawdę chcesz to zrobić” Unikałem korzystania z pip i wolałem korzystać z repozytorium systemowego, uciekając się do pip tylko wtedy, gdy potrzebuję zainstalować pakiet, który nie znajduje się w repozytorium.

Ponieważ jednak jest to niespójna metoda instalacji, czy lepiej byłoby używać tylko pip? Jakie są korzyści / przeszkody w korzystaniu z pipa nad własnym repozytorium systemu dla pakietów dostępnych w obu miejscach?

Link zawierałem stany

Zaletą korzystania ze standardowych pakietów Debian / NeuroDebian jest to, że są one dokładnie testowane pod kątem zgodności ze sobą. Pakiety Debiana rejestrują zależności z innymi bibliotekami, więc zawsze dostaniesz potrzebne biblioteki w ramach instalacji.

Używam arch. Czy tak jest w przypadku innych systemów zarządzania pakietami oprócz apt?

Największą wadą, jaką widzę przy pipinstalowaniu modułów Pythona w systemie, zarówno jako modułów systemowych, jak i modułów użytkownika, jest to, że system zarządzania pakietami Twojej dystrybucji nie będzie o nich wiedział. Oznacza to, że nie będą one używane w żadnym innym pakiecie, który ich potrzebuje i który możesz chcieć zainstalować w przyszłości (lub który może zacząć korzystać z jednego z tych modułów po aktualizacji); skończysz wtedy zarówno pipwersjami modułów zarządzanymi przez dystrybucję, jak i tymi, które mogą powodować problemy ( ostatnio natknąłem się na kolejną instancję tego ). Twoje pytanie jest więc propozycją „wszystko albo nic”: jeśli tylko użyjeszpip w przypadku modułów Python nie można już używać menedżera pakietów swojej dystrybucji do niczego, co chce używać modułu Python ...

Ogólna rada podana na stronie, do której linkujesz, jest bardzo dobra: staraj się wykorzystywać pakiety dystrybucji w miarę możliwości, używaj tylko pipdla modułów, które nie są spakowane, a kiedy to zrobisz, zrób to w konfiguracji użytkownika, a nie w systemie szeroki. W miarę możliwości korzystaj ze środowisk wirtualnych, w szczególności do programowania modułów. Zwłaszcza w Arch nie powinieneś napotykać problemów spowodowanych przez starsze moduły; nawet w przypadku dystrybucji, w których może to stanowić problem, środowiska wirtualne radzą sobie z tym dość łatwo.

Zawsze warto wziąć pod uwagę, że biblioteka biblioteki i pakiety modułów są pakowane przede wszystkim do użytku z innymi pakietami w dystrybucji; posiadanie ich jest przyjemnym efektem ubocznym programowania przy użyciu tych bibliotek i modułów, ale nie jest to podstawowy przypadek użycia.

TL; DR

• używaj pip(+ virtualenv) do różnych rzeczy (biblioteki, frameworki, może narzędzia programistyczne) , których używają twoje projekty (które tworzysz)
• użyj menedżera pakietów dla aplikacji, z których korzystasz (jako użytkownik końcowy)

Zależności programistyczne

Jeśli tworzysz oprogramowanie w Pythonie, zechcesz używać pipwszystkich zależności projektu, niezależnie od tego, czy są to zależności środowiska wykonawczego, zależności czasu kompilacji lub rzeczy potrzebne do zautomatyzowanego testowania i automatycznych kontroli zgodności (linijka, sprawdzanie stylu, sprawdzanie typu statycznego ...)

Istnieje kilka powodów:

• Pozwala to na użycie virtualenv (bezpośrednio lub za pomocą virtualenvwrapper lub pipenv lub w inny sposób) do oddzielenia wzajemnych zależności między różnymi projektami i odizolowania aplikacji pythonowych używanych w produkcji (jako użytkownik) od jakichkolwiek egzotycznych shenaniganów (lub nawet po prostu niezgodności), które mogą się rozwijać.
• Umożliwia to śledzenie wszystkich zależności projektu w pliku requirements.txt(jeśli projekt jest aplikacją) lub setup.py(jeśli projekt jest biblioteką lub strukturą). Można to sprawdzić w kontroli wersji (np. Git) razem z kodem źródłowym, aby zawsze wiedzieć, która wersja kodu opiera się na wersjach zależności.
• Powyższe umożliwia innym programistom współpracę przy projekcie, nawet jeśli nie używają tej samej dystrybucji Linuksa lub nawet tego samego systemu operacyjnego (jeśli używane zależności są również dostępne na komputerach Mac i Windows lub cokolwiek, z czego się korzystają, to znaczy)
• Nie chcesz, aby automatyczne aktualizacje menedżera pakietów systemu operacyjnego powodowały uszkodzenie kodu. Powinieneś zaktualizować swoje zależności, ale powinieneś to robić świadomie, a czasem wybierasz, abyś był gotowy naprawić swój kod lub wycofać aktualizację. (Co jest łatwe, jeśli śledzisz pełną deklarację zależności w systemie kontroli wersji wraz z kodem).

Jeśli uważasz, że musisz oddzielić bezpośrednie i pośrednie zależności (lub rozróżnić akceptowalny zakres wersji dla zależności i faktycznej wersji, patrz „przypinanie wersji”), zajrzyj do narzędzi pip i / lub pipenv. Umożliwi to także rozróżnienie między zależnościami kompilacji i testów. (Rozróżnienie między zależnościami kompilacji i środowiska wykonawczego można prawdopodobnie zakodować setup.py)

Aplikacje, których używasz

Dla rzeczy, których używasz jako normalnej aplikacji i które akurat są napisane w Pythonie, wolisz menedżera pakietów systemu operacyjnego. Sprawi, że będzie on w miarę aktualny i kompatybilny z innymi rzeczami instalowanymi przez menedżera pakietów. Większość dystrybucji Linuksa twierdzi również, że nie rozpowszechnia złośliwego oprogramowania.

Jeśli coś, czego potrzebujesz, nie jest dostępne w domyślnym repozytorium pakietu Twojej dystrybucji, możesz sprawdzić dodatkowe repozytorium pakietów (np. Starter dystrybucji opartej na deb) lub użyć pipmimo to. Jeśli to drugie, użyj --userdo instalacji w domu użytkownika zamiast w całym systemie, aby zmniejszyć ryzyko awarii instalacji Pythona. (Do rzeczy, których potrzebujesz tylko tymczasowo lub rzadko, możesz nawet użyć virtualenv.)

Innym powodem korzystania z menedżera pakietów jest to, że aktualizacje będą automatycznie stosowane, co ma kluczowe znaczenie dla bezpieczeństwa. Pomyśl, jeśli użyty pakiet fasoli Equifax został automatycznie zaktualizowany przez yum-cron-security, hack mógł się nie zdarzyć.

Na moim osobistym urządzeniu deweloperskim używam Pip, w prod używam pakietów.

Jeśli mówimy o instalowaniu pakietów Pythona do użycia w pisanym kodzie, użyj pip.

Dla każdego projektu, nad którym pracujesz, utwórz środowisko wirtualne, a następnie użyj pip, aby zainstalować tylko te elementy, których potrzebuje ten projekt. W ten sposób instalujesz wszystkie używane biblioteki w spójny sposób, są one zawarte i nie zakłócają niczego, co instalujesz za pomocą menedżera pakietów.

Jeśli planujesz opublikować dowolny kod Pythona, zazwyczaj dodasz do projektu a setup.pylub requirements.txt, co pozwoli pipowi automatycznie uzyskać wszystkie jego zależności. Umożliwia łatwe tworzenie lub odtwarzanie środowiska wirtualnego dla tego projektu.

Podsumowanie

Istnieją trzy ogólne kategorie modułów, z którymi masz do czynienia:

1. Te programy pomocnicze zainstalowane dla wszystkich użytkowników z systemem pakietów OS. (Może to nawet obejmować narzędzia i biblioteki używane przez osoby programujące się w Pythonie; patrz poniżej.) W tym celu korzystasz z pakietów systemu operacyjnego, gdzie możesz, i pipinstaluje się w katalogach systemowych, jeśli to konieczne.
2. Te wspierające programy instalowane przez konkretnego użytkownika tylko na własny użytek, a także dla niektórych aspektów jej codziennego używania Pythona jako języka skryptowego. Do tych używa ona pip --user, być może pyenv lub pythonz , i podobne narzędzia i taktyki.
3. Wspierające rozwój i wykorzystanie konkretnej aplikacji. Do tego używasz virtualenv(lub podobnego narzędzia).

Każdy poziom tutaj może również otrzymywać wsparcie z poprzedniego poziomu. Na przykład nasz użytkownik w (2) może polegać na interprecie Pythona zainstalowanym za pośrednictwem pakietów systemu operacyjnego.

Wchodząc w to bardziej szczegółowo:

Programy systemowe i pakiety

Programy napisane w Pythonie, które chcesz „po prostu uruchomić”, są proste: wystarczy użyć narzędzi instalacyjnych systemu operacyjnego i pozwolić im przynieść wszystko, czego potrzebują; nie różni się to od programu innego niż Python. Może to przynieść narzędzia / biblioteki Pythona (takie jak sam interpreter Pythona!), Na których użytkownicy na twoim komputerze mogą polegać; nie jest to problem, o ile rozumieją zależność i, najlepiej, znają alternatywne sposoby radzenia sobie z nią na hostach, które nie zapewniają tych zależności.

Typowym i prostym przykładem takiej zależności jest kilka moich osobistych skryptów od ~/.local/bin/tego #!/usr/bin/env python. Będą działać dobrze (o ile działają pod Pythonem 2) na RH / CentOS 7 i większości (ale nie wszystkich) instalacjach Ubuntu; nie będą one w ramach podstawowej instalacji Debiana ani w systemie Windows. Chociaż nie podoba mi się to, że moje osobiste środowisko ma wiele zależności od pakietów OS (pracuję na wielu różnych systemach operacyjnych), coś takiego wydaje mi się całkiem do przyjęcia; moim planem tworzenia kopii zapasowych na rzadkich hostach, które nie mają systemowego Pythona i nie mogą go uzyskać, jest system użytkownika opisany poniżej.

Ludzie używający systemowego interpretera python są zwykle zależni od systemu pip3. To o tym, gdzie zwykle rysuję linię w zależnościach mojego systemu; wszystko od virtualenvprzodu radzę sobie ze sobą. (Na przykład mój standardowy skrypt aktywacyjny opiera się na czymkolwiek pip3lub pipznajduje się na ścieżce, ale pobiera własną kopię, virtualenvaby uruchomić środowisko wirtualne, które tworzy.

To powiedziawszy, są prawdopodobnie okoliczności, w których całkowicie rozsądne jest udostępnienie większej ilości środowiska programistycznego. Możesz mieć interfejsy Pythona w złożone pakiety (takie jak DBMS), w których chcesz użyć wersji systemowej, i czujesz, że najlepiej jest, aby system wybrał konkretny kod biblioteki Pythona, z którym będziesz rozmawiać. Lub możesz wdrażać wiele hostów z podstawowym środowiskiem programistycznym dla klasy Python, i łatwiej jest zautomatyzować je za pomocą standardowych pakietów systemowych.

Użytkownik „codzienne” programy i pakiety

Użytkownicy mogą mieć biblioteki lub programy Python, które nie pasują dobrze do środowiska wirtualnego, ponieważ chcą przede wszystkim pomóc w tworzeniu środowisk wirtualnych (np. Virtualenvwrapper ) lub są to rzeczy, których zwykle używasz z wiersza poleceń, nawet gdy wykonując pracę nie w języku Python. Nawet jeśli mają możliwość instalowania ich wersji systemowych, mogą czuć się bardziej komfortowo, instalując własne (np. Ponieważ chcą korzystać z najnowszej wersji narzędzia i jego zależności).

Zasadniczo pip --userludzie będą do tego używać, chociaż niektóre zależności, takie jak sam interpreter Pythona, wymagają nieco więcej. pyenv i pythonz są przydatne do budowania osobistych interpreterów (niezależnie od tego, czy są zainstalowane ~/.local/binjako domyślny interpreter, czy też w inny sposób) i oczywiście zawsze można po prostu zbudować „ręcznie” ze źródła, jeśli biblioteki programistów są dostępne.

Staram się zachować tutaj minimalny zestaw rzeczy: virtualenvwrapper (ponieważ używam go stale) i być może najnowszą wersję pipa. Staram się unikać zależności poza standardową biblioteką lub w Pythonie 3 dla osobistych skryptów, które piszę, aby mogły być używane na wielu hostach. (Chociaż zobaczymy, jak długo wytrzymam, przenosząc coraz więcej osobistych skryptów do Pythona).

Oddzielne środowiska programowania aplikacji i środowiska wykonawczego

Jest to zwykła sprawa virtualenv. Do programowania prawie zawsze powinieneś używać virtualenv, aby upewnić się, że nie używasz zależności systemowych, lub często więcej niż jednej do testowania różnych wersji Pythona.

Te środowiska wirtualne są również dobre dla aplikacji z wieloma zależnościami, w których chcesz uniknąć zanieczyszczenia środowiska użytkownika. Na przykład zazwyczaj konfiguruję virtualenv do uruchamiania notesów Jupyter i tym podobnych.