Kiedy myślę o zaletach i wadach statycznego folderu biblioteki i menedżera pakietów, mam wrażenie, że folder biblioteki jest lepszym rozwiązaniem.
Plusy, które widzę w folderze biblioteki:
- Nie potrzebujesz zewnętrznego narzędzia do zarządzania pakietami.
- Kompilacja nie wymaga połączenia z Internetem.
- Szybsza kompilacja (bez sprawdzania pakietu).
- Prostsze środowisko (wymagana mniejsza wiedza).
Plusy, które widzę z menedżerem pakietów:
- Pomaga przy złożonych drzewach zależności (i którym można zarządzać pobierając zależność wraz ze wszystkimi jej zależnościami).
- Pomaga sprawdzić, czy dostępna jest nowa wersja.
Wygląda na to, że branża zdecydowała się podążać ścieżką menedżera pakietów dla prawie wszystkiego, co zbudowano dzisiaj. Więc czego mi brakuje?
packages
dependency-management
package-managers
Ignacio Soler Garcia
źródło
źródło
Odpowiedzi:
W innych odpowiedziach brakuje ważnego punktu:
Korzystanie z menedżera pakietów oznacza konfigurację, która wskazuje, których wersji biblioteki używasz i upewnia się, że informacje o konfiguracji są rzeczywiście poprawne.
Znajomość używanych bibliotek i wersji jest bardzo ważna, jeśli:
Ponadto, podczas faktycznej aktualizacji menedżer pakietów (zwykle) upewnia się, że wszelkie zależności przechodnie są aktualizowane zgodnie z wymaganiami.
Podczas gdy w
libfolderze masz tylko kilka (prawdopodobnie binarnych i prawdopodobnie zmodyfikowanych) plików i będziesz musiał zgadnąć, skąd pochodzą i jakiej wersji są (lub zaufać niektórym plikom README, co może, ale nie musi być poprawne ).Aby odnieść się do innych punktów
To prawda, ale a) jako programista i tak musisz zainstalować mnóstwo narzędzi, więc jedno dodatkowe zwykle nie ma znaczenia, i b) zwykle w jednym polu jest tylko jeden lub kilka menedżerów pakietów (Maven / Gradle dla Java, npm dla JS / TypeScript itp.), więc nie trzeba instalować dziesiątek.
Wszyscy menedżerowie pakietów, których znam, działają w trybie off-line, gdy pobiorą wymagane zależności (co może się zdarzyć zaraz po pobraniu samego projektu).
Prawdopodobnie prawda, ale wydaje się mało prawdopodobne, że sprawdzenie pakietu offline zajmie dużo czasu (to tylko porównanie niektórych numerów wersji). Internecie Kontrola może trochę potrwać, ale to może być wyłączona w razie potrzeby (jeśli jest nawet domyślnie - Maven na przykład nigdy nie sprawdza dostępność aktualizacji dla wersji Release).
To prawda, ale jak wyjaśniono powyżej,
libfolder wymaga również wiedzy. Ponadto, jak wyjaśniono powyżej, prawdopodobnie będziesz pracować tylko z kilkoma menedżerami pakietów różnicowych, które już znasz.źródło
Plusy folderu lib znikają szybko po przejściu z programowania na małą skalę do większej pracy.
Na przykład „korzyść” z niewymagania zewnętrznego narzędzia jest atutem pracy wymaganej do ręcznego zarządzania zależnościami, więc narzędziem będzie Ty (w więcej niż jednym sensie świata).
Menedżer pakietów nie potrzebuje połączenia z Internetem. Możesz korzystać z lokalnych repozytoriów.
Szybsza kompilacja może być prawdą, ale nie jest to coś, co powinno decydować o tym, czy użyć menedżera pakietów, czy nie. W końcu nie mówimy o wielkościach różnic, a to także zależy od twojej konfiguracji. Możesz łatwo wykonać powolną kompilację za pomocą menedżera pakietów, ale to w zasadzie sabotaż.
Prostsze środowiska (wymagana mniejsza wiedza)? Ponownie, w rozwoju na małą skalę zdecydowanie możliwość. Być może będziesz w stanie całkowicie trzymać projekt w głowie, aż do każdej z kilku używanych bibliotek. Dodaj prosty skrypt kompilacji makefile / other, a otrzymasz kompletny pakiet.
Ale to nie uczynić środowisk prostsze, to działa tylko w prostych warunkach. W rozwoju na większą skalę będziesz zadowolony, że używasz standardowych narzędzi zamiast niestandardowych rozwiązań. W końcu musisz się tego nauczyć tylko raz (a kiedy menedżer paczek du Jour zostanie zastąpiony przez nową fajną rzecz, musisz się tego także nauczyć).
źródło
blah install libfoo. A następnie pomnóż to przez powiedzmy 5 zależności.Brakuje wielu zalet menedżerów pakietów.
Przeceniasz także wartość swoich „korzyści”.
„Zewnętrzne” do czego? Sprawdzam plik wykonywalny NuGet w moich repozytoriach. To jedyny plik binarny, w którym czuję się dobrze, ponieważ jest mały i oznacza, że nie muszę sprawdzać żadnych innych plików binarnych.
pip nie stwarza problemów na tym froncie, ponieważ jest teraz domyślnie dołączony do Pythona, a łamanie i wstecznie niezgodne zmiany są niezwykle rzadkie. W każdym razie nie zamierzasz tworzyć kodu Python bez zainstalowania Pythona zewnętrznie w twoim projekcie.
Do czasu powszechnego przyjęcia, menedżerowie pakietów są zwykle bardzo stabilni. Nie można uciec bez jakiegoś globalnie zainstalowanego oprzyrządowania dla większości projektów, a pojedynczy menedżer pakietów jest dość niewielkim wymaganiem. Zwykle nie jest to dużo bardziej kłopotliwe niż zainstalowanie środowiska uruchomieniowego języka.
Nie mogę połączyć się z bazą danych bez połączenia sieciowego. Jeśli baza danych jest hostowana przez Amazon, i tak potrzebuję pełnego połączenia z Internetem. Potrzebuję połączenia z Internetem, aby wypychać i wyciągać zmiany poprzez kontrolę źródła; serwer kompilacji nie może również wypisać kodu do kompilacji bez pewnego połączenia sieciowego. Bez niej nie można wysyłać ani odbierać wiadomości e-mail . Nie można pobrać bibliotek, aby umieścić je w folderze lib bez niego! Ciągły rozwój bez połączenia z Internetem jest praktycznie niespotykany. W niektórych rzadkich przypadkach, gdy jest to konieczne, możesz sobie z tym poradzić, pobierając pakiety do lokalizacji, w której menedżer pakietów może korzystać. (Wiem, że NuGet i pip są bardzo zadowolone z pobierania z prostego folderu lub dysku sieciowego; podejrzewam, że większość innych również.)
30 sekund podczas automatycznej kompilacji i 5 sekund podczas lokalnych kompilacji programistów to dobry kompromis dla korzyści, które przedstawiłem powyżej. Są to trywialne ramy czasowe, które zwykle nie są nawet warte rozważenia w porównaniu z problemami, które rozwiązują korzyści.
Jedno narzędzie do zarządzania pakietami do niczego w przypadku zarządzania bibliotekami nie jest tak naprawdę uczciwym porównaniem. Bez tego narzędzia musisz nauczyć się dowolnego niestandardowego procesu używanego przez projektzarządzać bibliotekami. Oznacza to, że nigdy nie masz pewności, czy twoja wiedza dotyczy każdego nowego projektu, do którego się zbliżasz. Będziesz musiał poradzić sobie z tym, co ktoś wymyślił, lub wymyślić własne. Może to być katalog zawierający wszystkie biblioteki lub może być coś znacznie dziwniejszego. Być może, aby uniknąć sprawdzania bibliotek, ktoś umieścił je wszystkie na dysku sieciowym, a jedynym wskaźnikiem wersji jest nazwa folderu. W jaki sposób ta globalna instalacja jest naprawdę lepsza? Dla porównania, menedżer pakietów zapewnia czystą konwencję, która będzie obowiązywać w większości napotkanych projektów.
Wspólnym tematem jest to, że zapewniają spójność, dokumentację i funkcje nie tylko w ramach projektów, ale nawet w ich obrębie. To upraszcza życie każdego.
źródło
Po niedawnym przekonwertowaniu naszego produktu z używania ręcznie pobieranych bibliotek na automatyczne zarządzanie pakietami w Nuget, mogę powiedzieć, że korzystanie z menedżera pakietów ma ogromne zalety.
Nasz produkt jest wdrażany w 27 projektach C #, które są stosunkowo niewielkie jak na dzisiejsze standardy. Niektóre z naszych zależności od stron trzecich mają dziesiątki zespołów.
Przed Nugetem, gdybym chciał zaktualizować wszystkie nasze zależności do najnowszej wersji, musiałbym:
Z 27 projektami i dziesiątkami zestawów zależności proces ten był bardzo podatny na błędy i mógł zająć wiele godzin.
Teraz, gdy zaktualizowaliśmy się do korzystania z Nuget, wszystko zostało zrobione dla mnie za pomocą jednego polecenia.
źródło
To trochę bez sensu, prawda? Jeśli korzystam z menedżera pakietów, nie muszę mieć folderu lib. Nie muszę też samodzielnie zarządzać pakietami.
Poza tym brak obecnie połączenia internetowego podczas programowania jest dość rzadki (być może z wyjątkiem bycia w drodze), przyzwoity menedżer pakietów nie powinien wymagać od ciebie najnowszej wersji do zbudowania aplikacji. Może narzekać, ale nie ma powodu, aby nie budować z wersją, którą już zainstalował
To dość marginalne przyspieszenie, ale prawdopodobnie można to zrobić.
Większość menedżerów pakietów jest obecnie tak prosta, że nie warto próbować ich obejść. Są nawet klienci wizualni, jeśli chcesz. W rzeczywistości ukrywają wiele upraw, które się toczą.
Menedżerowie pakietów umożliwiają także współdzielenie tych pakietów między różnymi projektami. Jeśli 5 z moich projektów używa tej samej wersji Boost, nie ma potrzeby kopiowania tego dla każdego projektu. Jest to szczególnie prawdziwe w przypadku złożonych drzew zależności, o których mówisz.
Za pomocą folderu lib zarządzasz pakietami tylko dla tego projektu, a menedżer pakietów pozwala to zrobić dla całego środowiska programistycznego za pomocą jednego narzędzia.
źródło
nuget.org(szablon domyślny powinien już skonfigurowane w ten sposób).Jest to różnica między używaniem bibliotek (katalogu lib) , a używaniem ich, utrzymaniem meta-informacji (menedżer pakietów) . Takie meta-informacje dotyczą numerów wersji, (przechodnich) zależności między bibliotekami i tym podobne.
Dyskusje o piekle DLL, kompatybilności bibliotek, systemie modułów Java, OSGi i tym podobnych powinny być przynajmniej wystarczającym przekonaniem o pewnej wartości posiadania pewnej formy zarządzania zależnościami.
Zaletą jest wspólne (lokalne) repozytorium, więc kilka projektów nie musi utrzymywać kopii importowanych bibliotek. Jeśli jeden ma projekt z 20 submodułami, niektóre z tych modułów mają 40 dziwnych zależności.
źródło
W niektórych przypadkach może być potrzebny folder lib, na przykład w przypadku przestarzałych bibliotek (jego wersja nie jest już utrzymywana / dostępna), lokalnie zmodyfikowana wersja biblioteki, ...
Ale wszystko inne przypomina programistę przyjmującego rolę menedżera pakietów:
IMHO wymaga mniej wiedzy, ponieważ musisz nauczyć się korzystania z zewnętrznego narzędzia, a mniej bibliotek (tj. Zależności).
źródło
Istnieje inny problem nieobjęty innymi pytaniami: dzielenie się zależnością.
Powiedzmy, że masz dwa pakiety budujące tę samą bibliotekę. W najlepszym przypadku nie będzie żadnych awarii, ale ta sama przestrzeń na dysku HDD / SSD zostanie użyta dwukrotnie. W najgorszym przypadku wystąpią konflikty varios, takie jak wersje.
Jeśli używasz menedżera pakietów, biblioteka instaluje się tylko raz (dla każdej wersji) i już zawiera ścieżkę do niego.
PS: oczywiście, potrzebujesz dynamicznego połączenia (lub podobnej funkcji w Twoim języku), aby uzyskać tego pro.
źródło
Jednym z głównych powodów, dla których biblioteki dzielone były uważane za postęp w systemach Unix i Windows z lat 90., było to, że mogły zmniejszyć zużycie pamięci RAM, gdy załadowano wiele programów korzystających z tego samego zestawu bibliotek. Przestrzeń kodu musi zostać przydzielona tylko RAZ na dokładną bibliotekę i wersję tej biblioteki , jedyne pozostałe użycie pamięci na wystąpienie dotyczy zmiennych statycznych.
Wiele systemów operacyjnych implementuje współdzielone biblioteki w sposób zależny od mechanizmów takich jak unix mmap () api - co oznacza, że biblioteka będzie musiała być nie tylko tą samą wersją, ale w rzeczywistości tym samym PLIKIEM. Jest to po prostu niemożliwe, aby w pełni skorzystać z programu, który dostarcza własny zestaw bibliotek.
Biorąc pod uwagę, że pamięć jest znacznie tańsza, a wersje biblioteczne wymagały większej różnorodności niż w latach 90., ten argument nie ma obecnie tak dużego znaczenia.
źródło