2010-06-16 16 views
5

Na Tiger użyłem niestandardowej instalacji pythona do oceny nowszych wersji i nie miałem żadnych problemów z tym *. Teraz Snow Leopard jest trochę bardziej up-to-date i domyślnie statków zW systemie Mac OS X używasz dostarczonego python lub własnego?

$ ls /System/Library/Frameworks/Python.framework/Versions/ 
2.3 2.5 2.6 @Current 

  • Co można uznać za najlepsze praktyki? Używając pytona dostarczonego z systemem Mac OS X lub niestandardowej wersji skompilowanej, powiedzmy $HOME.
  • Czy są jakieś zalety/wady, używając jednej opcji zamiast drugiej?

Moja konfiguracja była dość prosta do tej pory i wyglądał następująco: Niestandardowe skompilowany Python w $HOME i $PATH że będzie wyglądać w $HOME/bin pierwszy, a następnie będzie używać mojego prywatną wersji Pythona. Również $PYTHONPATH wskazał na tę lokalną instalację. W ten sposób nie musiałem instalować pakietów w wersji sudo - virtualenv zajmowała się resztą. Uwaga: Podobała mi się ta konfiguracja, więc jestem po prostu ciekawa i pomyślałem, że pytam umysłu ul .

Odpowiedz

5

Myślę, że to zależy od Twoich potrzeb. Osobiście używam najnowszej wersji dla każdej serii (2.5, 2.6 itd.) Z MacPorts.

+2

+1 dla Macports – systempuntoout

0

To, co robisz na komputerze, zależy wyłącznie od Ciebie. Jeśli masz zamiar wdrożyć swój kod na innych, powiedziałbym, że zdecydowanie lepiej jest użyć dostarczonej wersji, chyba że musisz naprawdę potrzebować nowszej wersji.

+1

Nie zgadzam się. Większość pakowanych programów python wysyła pythona wewnątrz paczki, i to jest właściwy sposób. Bóg wie, co instaluje użytkownik na swoim komputerze. – unbeli

+1

@unbeli Jeśli rozpowszechniasz odpowiednią aplikację, OK. Ale dla kilku skryptów? Dokładnie ilu pythonowych interpreterów potrzebuje maszyna? I bardziej ogólnie, jak to ma sens * nie * kodować dla podstawowego środowiska, jeśli wszystko inne jest równe? – walkytalky

+2

Cóż, skrypty nie są tak naprawdę "wdrożone", więc nie ma sposobu na spakowanie pythona. Nie ma podstaw, którym można zaufać. Wiem, że to jest do bani, ale takie jest życie, nikt nie obiecał, że to nie będzie ssać;) – unbeli

1

Problem z używaniem wersji Pythona dostarczonej z systemem operacyjnym jest taki, że może zawierać błędy lub być ograniczony w inny sposób. Jeśli instalujesz Pythona z Fink lub MacPorts, masz możliwość jego aktualizacji.

Inną, ważną zaletą zarządzania własną wersję Pythona z menedżera pakietów (Fink lub DarwinPorts) jest to, że pomagają one wiele z zestawiania zależności modułu (na przykład podczas korzystania z modułu, który zależy od skompilowany Kod C). W związku z tym instalacja modułów Pythona jest z pewnością łatwiejsza, jeśli nie używasz Pythona dostarczanego z OS X. Jest to ważny punkt do rozważenia przed dokonaniem wyboru.

2

Sam kompiluję, ponieważ to daje mi najnowszą wersję 64-bitową. Oficjalne wersje OS X wydają się być tylko 32-bitowe. Upuściłem MacPorts kilka miesięcy temu, ponieważ jego system zależności i często nieaktualne pakiety były zbyt irytujące.

0

Przeszukuję ten stary temat.

Nie ma prawdziwych odpowiedzi, aby utworzyć własną dystrybucję Pythona/frameworki ze źródła i pakietu i spakować je we właściwy sposób. Próbowałem skompilować go ze źródła, łącząc go z moją zaprogramowaną aplikacją C, która używa Pythona 3 i działa na moim komputerze. Ale kiedy przenoszę go w systemie plików (np. Do/tmp), ma on zakodowane ścieżki w kompilacji Pythona. I nie mam pojęcia, jaki skrypt/opakowanie do zrobienia.

Moim celem jest dostarczenie naszej własnej dystrybucji python, aby upewnić się, że nie ma żadnych dziwności w zmianie interpetowania podczas wysyłania aplikacji i polegać na instalacji Pythona dla systemu operacyjnego.

Nigdzie nie jest to udokumentowane w dokumentacji Pythona.

Znalazłem już ten wpis 4206511

Powiązane problemy