2009-10-13 10 views
11

Zazwyczaj mam tendencję do instalowania rzeczy za pośrednictwem menedżera pakietów, w przypadku plików uniksowych. Jednak gdy zaprogramowałem dużo perla, użyłbym CPAN, nowszych wersji i tak dalej.Który jest najbardziej pythonic: instalowanie modułów Pythona za pośrednictwem menadżera pakietów (macports, apt) lub poprzez pip/easy_install/setuptools

W ogóle, kiedyś zainstalować rzeczy systemu poprzez menadżera pakietów i język rzeczy poprzez jej własną menadżera pakietów (GEM/easy_install | PIP/cpan)

Teraz przy użyciu Pythona przede wszystkim zastanawiam się, co najlepsze praktyki jest ?

Odpowiedz

17

Systemowa wersja pythona i jej biblioteki są często używane przez oprogramowanie w dystrybucji. Tak długo, jak oprogramowanie, z którego korzystasz, jest zadowolone z tych samych wersji Pythona i wszystkich bibliotek, co twoja dystrybucja, to używanie pakietów dystrybucyjnych będzie działało dobrze.

Jednak często potrzebujesz wersji rozwojowej pakietów lub nowszej wersji lub starszych wersji. A potem już nie działa.

Dlatego zwykle zaleca się zainstalowanie własnej wersji Pythona, której używasz do programowania, i tworzenie środowisk programistycznych z buildout lub virtualenv lub obu, aby wyizolować python systemowy i środowisko programistyczne od siebie.

+1

[pyenv] (https://github.com/yyuu/pyenv#readme) to wspaniałe narzędzie do zarządzania wieloma wersjami Pythona i [virtualenvs] (https://github.com/yyuu/pyenv-virtualenv#readme). –

17

Istnieją dwa całkowicie przeciwstawne obozy: jeden na korzyść pakietów dostarczanych przez system i jeden na rzecz oddzielnej instalacji. Osobiście jestem w obozie "pakietów systemowych". Podam argumenty z każdej strony poniżej.

Pro pakiety systemowe: system packager już dba o zależności i zgodność z ogólnymi zasadami systemu (takimi jak układ pliku). Pakiety systemowe dostarczają aktualizacje zabezpieczeń, jednocześnie dbając o to, aby nie łamały kompatybilności - tak więc czasami zawierają one poprawki zabezpieczeń, których autorzy nie uwzględnili w backsporcie. Pakiety systemowe są "bezpieczne". uaktualnienia systemu: po aktualizacji systemu prawdopodobnie masz również nową wersję Pythona, ale wszystkie twoje moduły Pythona nadal istnieją, jeśli pochodzą z pakera systemowego. To wszystko jest osobiste doświadczenie z Debianem.

Pakiety systemu Con: nie wszystkie oprogramowanie może być dostarczone jako pakiet systemowy lub nie w najnowszej wersji; instalowanie różnych rzeczy w systemie może spowodować uszkodzenie pakietów systemowych. Aktualizacje mogą przerwać Twoją aplikację.

Pro osobna instalacja: niektóre osoby (w szczególności programiści aplikacji internetowych) twierdzą, że absolutnie potrzebujesz powtarzalnej konfiguracji, przy użyciu tylko tych pakietów, które zostały całkowicie odłączone od systemu Python. To wykracza poza samodzielne instalowanie w porównaniu do pakietów systemowych, ponieważ nawet w przypadku samodzielnej instalacji wciąż możesz modyfikować pythona systemowego; z oddzielną instalacją, nie będziesz. Jak omawia Lennart, istnieją teraz dedykowane łańcuchy narzędzi wspierające tę konfigurację. Ludzie twierdzą, że tylko to podejście może zagwarantować powtarzalne wyniki.

Skonfiguruj osobną instalację: musisz samodzielnie rozwiązać problem i upewnić się, że wszyscy użytkownicy korzystają z oddzielnej instalacji. W przypadku aplikacji internetowych ta ostatnia jest zwykle łatwa do osiągnięcia.

+0

Wystarczająco fair. Zawsze zastanawiam się, dlaczego setuptools, a zwłaszcza rubygems et al, nie instaluje się w drzewie/usr/local, które jest miejscem dla rzeczy, które są, lokalnie. Ach tak. Za to, co warto, będąc także sysadminem (czy nie wszystkie mamy wiele rzeczy?) Wolę twoje podejście. Wydaje się być dość problematyczny z pytonem.Trzymając się za nos i idąc "drogą rozwoju środowiska programistycznego" – chiggsy

+1

Całkowicie zgadzam się, że pakiety dystrybucyjne są preferowane podczas instalacji w systemie Python. Ale jeśli chodzi o prace rozwojowe, a także system produkcyjny, który dużo robi, będziesz potrzebował oddzielnych środowisk dla oddzielnego oprogramowania (chyba że wszystkie z nich będą dostarczane jako zaktualizowane i obsługiwane pakiety dystrybucyjne). –

+0

Jako politykę osobistą powstrzymuję się od używania oprogramowania, dla którego nie ma pakietu systemowego, lub wersji innej niż ta, którą zapewnia pakiet pakujący systemu. Może to oznaczać, że nie mogę korzystać z wielu pakietów - nieszczęście; Będę musiała uzupełnić rzeczy. Z drugiej strony, jestem ograniczony do używania "stabilnego" oprogramowania, więc właściwie nie muszę śledzić każdego wydania rozwojowego tylko dlatego, że jakaś biblioteka decyduje, że wymaga niewydanej wersji jakiegoś innego pakietu. –

Powiązane problemy