Dlaczego biblioteki są dostarczane oddzielnie zamiast w pakiecie z każdym programem?

Wiem, dlaczego jest to ogólnie dobre: ​​szybsze poprawki bezpieczeństwa, łatwiejsze pakowanie, więcej funkcji. Próbuję jednak przekonać niektórych współpracowników, że nie musimy dołączać biblioteki do naszego programu. Bez tej biblioteki nie będzie działać, ale biblioteka jest stabilna przez pewien czas i pozostanie taka w dającej się przewidzieć przyszłości. Nie widzę żadnego powodu, aby NIE rozpinać go.

Jakich argumentów mogę użyć, aby ich przekonać?

Moja konkretna sytuacja jest taka: pracuję nad SymPy , która jest biblioteką Pythona typu open source do matematyki symbolicznej. Jego podstawową częścią jest mpmath , która jest biblioteką dla arytmetyki zmiennoprzecinkowej z wieloma prognozami . SymPy nie działa bez mpmath, nie ma alternatywy. Jako taki, jest on dołączany do SymPy od samego początku (powiedziano mi, że zazwyczaj za każdym razem, gdy importowana jest nowa wersja, występują niewielkie niezgodności). Należy również zauważyć, że twórca mpmath był kiedyś zaangażowany w rozwój SymPy. Wystąpił problem z rozdziałem mpmath, możesz przeczytać to wszystko tutaj .

Podsumowując dyskusję:

Rozpakuj:

• Nieco łatwiejsze przenoszenie do Pythona 3 (drobny argument IMHO)

• Łatwiejsze pakowanie do dystrybucji

• Szybsze aktualizacje funkcji (bezpieczeństwa) dla użytkowników

• „Zależności od pakowania i przeładunku są trudnymi problemami, ale zostały rozwiązane. To zdecydowanie nie jest obszar, w którym powinniśmy robić swoje.”

Pakuj dalej:

• Instalacja. Jest łatwy w Linuksie, trudniejszy w Macu i bardzo trudny w Windowsie. Brak dostępu do su i inne problemy.

• jest integralną częścią SymPy, tzn. sympy nie działa bez niego (wcale)

• nie ma innego pakietu, który mógłby wykonać zadanie mpmath

• „Gdy jako użytkownik pobieram sympię, oczekuję, że po prostu zadziała”.

Taka jest moja szczególna sytuacja, ale przyjmuję odpowiedź, która zapewnia dobrą, ogólną odpowiedź.

Jeszcze jedna odpowiedź, ale ta, którą uważam za najważniejszą (tylko moje osobiste zdanie), choć pozostałe również są dobre.

Pakowanie biblioteki osobno pozwala na aktualizację biblioteki bez potrzeby aktualizacji aplikacji. Powiedz, że w bibliotece jest błąd, zamiast po prostu zaktualizować bibliotekę, musisz zaktualizować całą aplikację. Co oznacza, że ​​twoja aplikacja będzie potrzebować wersji bez zmian kodu nawet ze względu na lib.

Oprócz wspomnianych zalet (bezpieczeństwo, opakowanie, funkcje), mogę wymyślić jeszcze kilka:

• Ktoś, kto uznałby tę funkcjonalność za przydatną dla innego programu, nie musiałby dzielić jej na części. To znaczy, jeśli ona w ogóle wie, czy funkcjonalność istnieje w twoim projekcie w postaci biblioteki. To zależy od tego, jak dobrze jest zaprojektowany ... jeśli twój projekt jest wystarczająco modułowy.

• W przypadku, gdy jest to przydatne w innych projektach, ogólnie zmniejszyłoby to użycie dysku (np. Tylko jedna kopia kodu).

• Poprawiłoby to jakość twojego kodu, zmuszając cię do (bardzo potrzebnego) refaktoryzacji. Podobnie jak w pierwszym punkcie powyżej, zależy to również od jakości twojego kodu.

• Zwiększenie liczby użytkowników biblioteki (jeśli zostanie podzielona) pomogłoby uczynić ją bardziej ogólną, co prawdopodobnie poprawi również jej jakość.

Chociaż zalety są oczywiste, łatwość wdrażania wydaje się być głównym argumentem za dostarczeniem biblioteki wraz z programem w twoim przypadku.

Oto kilka argumentów przeciwko pakietowaniu:

• W Linuksie zadaniem opiekuna dystrybucji jest upewnienie się, że biblioteka działa dobrze z jej zależnościami. Większość użytkowników i tak pobierze bibliotekę za pomocą menedżera pakietów dystrybucji. Ci, którzy używają trunk, zazwyczaj nie będą mieli nic przeciwko spędzaniu czasu na konfigurowaniu biblioteki.

• W systemach Windows i Mac OS menedżery pakietów Python, takie jak pip, są zwykle używane, ponieważ ręczne instalowanie bibliotek jest uciążliwe.

• Dyskutowano nawet o trudnym wdrożeniu w silniku aplikacji Google, ale nie wszystkie frameworki działają na nim. Wiele z nich wymaga nawet przenoszenia, miejsce na dysku dla bibliotek jest ograniczone, a mimo to hostowanie aplikacji internetowych! Jest mało prawdopodobne, aby aplikacja internetowa używała matematyki symbolicznej.

• Nikt nie zapobiega wyświetlaniu czystych komunikatów o błędach, jeśli zależność nie jest dostępna lub ma niewłaściwą wersję.

• Ludzie często go nienawidzą, gdy program uważa się za mądrzejszego niż oni. Pozwól użytkownikom dbać o własny system.

Właściwy sposób obsłużyć uwolniony w oknach instalatora pakietu byłoby mieć test preinstalacyjnych dla istnienia biblioteki, a jeśli to nie jest obecny zaoferować go zainstalować z pakietu biblioteki, które należą do pakietu instalacyjnego oprogramowania. Jestem prawie pewien, że większość aplikacji GTK, które mają porty systemu Windows, robi coś w tym stylu - wiem, że robi to Pidgin .

Jeden rozmiar nie musi pasować do wszystkich.

W przypadku dystrybucji źródłowych, jeśli tworzysz pakiet, osoby pakujące w wielu dystrybucjach (przynajmniej dziedzictwo Debiana i Fedory) będą musiały wykonać dodatkową pracę, aby wyłączyć lub usunąć pakiet, ponieważ zasady pakietów dla tych platform zabraniają lub przynajmniej zdecydowanie zniechęcają do tworzenia pakietów. Dlatego łącząc pakiet, tworzysz więcej pracy dla swojego dalszego rynku, przy bardzo niewielkich korzyściach. Czy ten argument może mieć jakąś wagę?

Dystrybucje binarne (jeśli je podasz) mogą iść w obie strony; sprzedaż wiązana prawdopodobnie ma sens dla tych, ponieważ nie są one wykorzystywane przez downstream.

Ale nie ma powodu, dla którego nie można podjąć przeciwnej decyzji i pakietu dla instalatorów Windows i Mac.

Sprzedaż wiązana vs. zależna to stara debata w świecie opakowań. Ten dokument opowiada o tych dwóch szkołach myślenia: http://www.aosabook.org/en/packaging.html