Dlaczego wolisz menedżera pakietów niż folder biblioteki?

68

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:

  1. Nie potrzebujesz zewnętrznego narzędzia do zarządzania pakietami.
  2. Kompilacja nie wymaga połączenia z Internetem.
  3. Szybsza kompilacja (bez sprawdzania pakietu).
  4. Prostsze środowisko (wymagana mniejsza wiedza).

Plusy, które widzę z menedżerem pakietów:

  1. 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).
  2. 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
33
Wydaje mi się, że naprawdę pytasz o korzyści związane z pakietowaniem w porównaniu z wymaganiem bibliotek. Otrzymasz trafniejsze odpowiedzi, jeśli użyjesz tych terminów.
— Kilian Foth,
3
Co powstrzymuje Cię przed utworzeniem kontenera dokującego dla agenta kompilacji, zawierającego wszystko, co potrzebne, a nawet w ogóle nie pozwalającego na dostęp do Internetu (nie powinno to być potrzebne do budowania)? Myślę, że jesteś bardziej przeciwny uczeniu się nowego narzędzia niż rozważaniu argumentów. Czy kiedykolwiek pracowałeś nad dużym projektem, który wykorzystuje zależności zarządzane ręcznie? To nie jest tak wspaniałe, jak się wydaje.
— Kayaman
3
@Kayaman: nauczenie się nowego narzędzia kosztuje czas zespołu (pieniądze) i chciałbym sprawdzić, czy inwestujemy go we właściwą rzecz. Moje doświadczenie z dużymi projektami polega na tym, że zależności są dość stabilne [prawie nigdy się nie zmieniają] i może dlatego menedżer pakietów wydaje mi się drogi. W każdym razie właśnie wymieniałem plusy i minusy po pracy z Nuget i spędzeniu z tym trochę czasu.
— Ignacio Soler Garcia
2
@sebkur Możesz przechowywać lokalne kopie wszystkich swoich paczek. Trzymamy bieżące wersje wszystkich naszych zależności pod kontrolą lokalnego źródła. Menedżer pakietów potrzebuje tylko połączenia, kiedy wykonujemy aktualizacje.
— 17 z 26
1
@ 17of26: nie nauczysz się konfigurować agenta kompilacji, aby zainstalować nuget i uruchamiać go na żądanie w 10 minut. Nie dotyczy to również projektu z wieloma rozwiązaniami, w którym te same projekty są wykorzystywane w różnych rozwiązaniach.
— Ignacio Soler Garcia

Odpowiedzi:

122

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:

  • trzeba zaktualizować bibliotekę z powodu krytycznego błędu / dziury w zabezpieczeniach;
  • lub po prostu sprawdź, czy dotyczy cię zapowiedziana luka w zabezpieczeniach.

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

Nie potrzeba zewnętrznego narzędzia do zarządzania pakietami.

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.

Kompilacja nie wymaga połączenia z Internetem.

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).

Szybsza kompilacja (bez sprawdzania pakietu).

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).

Prostsze środowiska (wymagana mniejsza wiedza).

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.

— Śleske
źródło
170
„Nie potrzeba zewnętrznego narzędzia do zarządzania pakietami” - tak. Teraz to praca twojego mózgu. Powodzenia, mózg!
— Paul D. Waite
57
Każdy, kto poważnie myśli, że posiadanie folderu lib jest „łatwiejszym środowiskiem”, powinien po prostu spróbować znaleźć drzewo zależności, na przykład model Microsoft.AspNetCore.All . Dalej, nie czekaj na mnie, odprawię się za około dzień.
— Voo
13
Również przeglądarka internetowa, której używasz do ręcznego wyszukiwania bibliotek, byłaby liczona jako zewnętrzne narzędzie do zarządzania pakietami. Wraz ze wszystkim innym, czego używasz (menedżer plików systemu operacyjnego itp.) Do przygotowania i pozycjonowania bibliotek. Tak więc prawdziwym wyborem jest jedno narzędzie zewnętrzne (menedżer pakietów) zamiast wielu.
— NemesisX00
3
Tylko do Twojej wiadomości, ostatnio próbowałem pracować z gradle na komputerze offline. Nie mam szczęścia, Android Studio nie uruchamia mojej aplikacji i pojawia się niejasny komunikat o błędzie, i to po tym, jak wykonałem pierwsze uruchomienie online dla zależności. Tylko w takich sytuacjach naprawdę widać, jak zależne jest od menedżerów pakietów tworzących oprogramowanie ...
— FRob
7
@ PaulD.Waite Gdy już to robimy, pozbyliśmy się tych irytujących „języków”, o których wszyscy mówią. W końcu wszystko sprowadza się do kodu maszynowego, więc w mojej firmie odcięliśmy pośrednika. To jest efektywność!
— corsiKa
39

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ć).

— Kayaman
źródło
21
@IgnacioSolerGarcia: Jest to łatwiejsze tylko wtedy, gdy nic nie pójdzie źle. Co jeśli nowa wersja biblioteki A również potrzebuje zaktualizowanej wersji B i C? Co jeśli nadal działa, ale wprowadza subtelne błędy? To wszystko jest częścią „zarządzania zależnościami”.
— sleske
18
@IgnacioSolerGarcia mówiąc „pobierz plik” nie do końca maluje poprawne zdjęcie. Powiedzmy „pobierz 20 plików i upewnij się, że ich wersje są kompatybilne”. Nie uniknięto tam żadnej pracy. Aktualizacja pakietów też nie jest sytuacją teoretyczną, chyba że zdecydujesz się zamrozić wersje zależności i będziesz gotowy zaakceptować możliwe problemy (błędy, wady bezpieczeństwa) wynikające z tego.
— Kayaman
12
@IgnacioSolerGarcia „pobierz plik” - czy miałeś na myśli (1) znalezienie poprawnej strony internetowej projektu (niektóre są hostowane na github, niektóre na sourceforge, niektóre na własnych stronach), (2) przejdź do strony pobierania, (3) znajdź poprawną wersję , (4) pobierz, (5) rozpakuj i upuść gdzieś. To wydaje się o wiele więcej pracy niż blah install libfoo. A następnie pomnóż to przez powiedzmy 5 zależności.
— el.pescado
5
@IgnacioSolerGarcia Ok, które pliki „po prostu” muszę pobrać, aby ten nuget działał poprawnie? I to w zasadzie najbardziej trywialna konfiguracja projektu ASP.NET Core. W praktyce będziesz mieć znacznie więcej zależności.
— Voo
6
@Ignacio To podstawowy meta-nuget umożliwiający uruchomienie najprostszej aplikacji ASP.Net Core. To prawda, że ​​w dawnych dobrych czasach pełnego frameworku wszystko było „łatwiejsze”, ponieważ otrzymałeś właśnie duże monolityczne biblioteki, które były jednocześnie wersjonowane, a wydanie aktualizacji zajęło ci lata. Ten model został zasadniczo przestarzały z bardzo dobrych powodów, nie tylko w świecie .NET. Musisz przyzwyczaić się do całego modelu wielu małych bibliotek wykonujących jedną konkretną czynność, a uczciwe korzystanie z menedżera pakietów jest najłatwiejszą częścią przejścia.
— Voo
35

Brakuje wielu zalet menedżerów pakietów.

  1. Menedżery pakietów pozwalają uniknąć sprawdzania dużych (kilku megabajtów lub większych) plików binarnych w celu kontroli źródła. Takie działanie jest przekleństwem dla wielu narzędzi kontroli źródła, a wszechobecny git jest jednym z nich. Kilka miesięcy temu mieliśmy w repozytorium limit wielkości Bit Bucket, ponieważ programiści sprawdzali CocoaPods. Inny projekt był już w połowie drogi, gdy przeprowadziliśmy migrację z SVN, ponieważ sprawdzaliśmy wszystkie nasze pliki binarne lib (i nie korzystaliśmy z NuGet). Ponieważ menedżerowie pakietów będą pobierać pakiety w locie dla każdego programisty, eliminują potrzebę sprawdzania tych plików binarnych.
  2. Zapobiegają mieszaniu niekompatybilnych plików / bibliotek. Foldery mogą zawierać mieszane wersje plików biblioteki, jeśli ktoś nie wyczyści go poprawnie podczas aktualizacji. Widziałem przypadek, w którym połowa plików binarnych w folderze została zaktualizowana, co spowodowało bardzo dziwne błędy. (Nawet się nie zawiesił!) Zajęło nam dosłownie miesiące (nie roboczogodziny, tylko ogólny czas), aby rozwiązać problem. Pozwalając menedżerowi pakietów kontrolować cały folder, nie można uzyskać wersji mieszanych; zapewniasz spójność. Utrudniają także korzystanie z niezgodnych zależności , automatycznie aktualizując wszystko razem, instalując różne wersje w razie potrzeby, a nawet rzucając ostrzeżenia lub błędy podczas próby użycia niekompatybilnych wersji bibliotek.
  3. Ustanawiają wspólną konwencję zarządzania bibliotekami. Kiedy nowi programiści przychodzą do twojego projektu, zespołu, firmy itp., Prawdopodobnie znają konwencje menedżera pakietów. Oznacza to, że nie muszą tracić czasu na ustalanie dokładnych szczegółów zarządzania bibliotekami w bazie kodu.
  4. Zapewniają standardowy sposób wersjonowania i rozpowszechniania własnych zależności i plików, które nie należą do twojego repozytorium. Nawet osobiście wykorzystałem je w przypadku niektórych dużych plików danych statycznych, których wymagała moja aplikacja, więc działa dobrze do wersjonowania rzeczy oprócz kodu binarnego.
  5. Niektóre menedżery pakietów zapewniają dodatkowe funkcje podczas instalacji. NuGet doda zależności i pliki zawartości do pliku csproj, a nawet doda elementy konfiguracyjne do pliku konfiguracyjnego.
  6. Pliki listy pakietów dokumentują wersje bibliotek w jednym, scentralizowanym miejscu. Nie muszę klikać prawym przyciskiem myszy biblioteki DLL i patrzeć na numer wersji, aby dowiedzieć się, jakiej wersji biblioteki używam. W Pythonie autor biblioteki mógł nawet nie zawrzeć numeru wersji w plikach py, więc może nawet nie będę w stanie odróżnić od nich wersji biblioteki.
  7. Odradzają instalację zależności w całej maszynie. Menedżerowie pakietów zapewniają konwencjonalny sposób instalowania zależności bez globalnego instalatora . Gdy twoimi opcjami są folder lib i instalacja globalna, wielu deweloperów bibliotek zdecyduje się zaoferować swoje biblioteki przede wszystkim jako instalacje globalne, a nie jako pliki binarne do pobrania, które musisz samodzielnie skonfigurować. (Historia MS to pokazuje. Dotyczy to również wielu bibliotek w Linuksie). To faktycznie utrudnia zarządzanie wieloma projektami, ponieważ możesz mieć projekty o sprzecznych wersjach, a niektórzy programiści z pewnością wybiorą pozornie prostszą instalację globalną niż posiadanie własnej biblioteki lib reż.
  8. Mają tendencję do centralizacji hostingu i dystrybucji. Nie musisz już polegać na stronie losowej biblioteki. Jeśli przestaną działać, witryna odnoszącego sukcesy menedżera pakietów nadal ma wszystkie przesłane wersje. Programiści nie muszą również przeszukiwać wielu stron internetowych, aby pobrać nowe biblioteki; mają miejsce, w którym najpierw mogą szukać, a nawet przeglądać różne opcje. Łatwiej jest także tworzyć kopie lustrzane paczek zorganizowanych w standardowy sposób niż ręcznie przechowywać kopie wszystkiego ze stron ad-hoc.

Przeceniasz także wartość swoich „korzyści”.

  1. Nie potrzeba zewnętrznego narzędzia do zarządzania pakietami.

    „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.

  2. Kompilacja nie wymaga połączenia z Internetem.

    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ż.)

  3. Szybsza kompilacja (bez sprawdzania pakietu).

    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.

  4. Prostsze środowiska (wymagana mniejsza wiedza).

    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.

— jpmc26
źródło
10
„Ciągłe rozwijanie się bez połączenia z Internetem jest praktycznie niesłychane” Żałuję, że nie wiedziałem lepiej. Ze względów bezpieczeństwa dokonano wielu prac rozwojowych w całkowicie oddzielnych sieciach. Tak, jest to tak samo zabawne, jak się wydaje, ale jest absolutnie wykonalne. Musisz tylko skonfigurować własną infrastrukturę do przechowywania pakietów (tj. Własny kanał nuget).
— Voo
1
Chociaż posiadanie własnej infrastruktury jest w rzeczywistości jedną z niewielu rzeczy, które mają sens w każdym przypadku: nie chcesz być niezawodnym w infrastrukturze zewnętrznej. Jeśli ten nie jest dostępny z tego czy innego powodu, znacznie lepiej jest mieć rezerwę, która gwarantuje, że Twoi programiści mogą kontynuować rozwój. (I zanim ktokolwiek powie mi, że ten nuget.org, npm lub <wstaw ulubione repozytorium pakietów> nigdy nie miałby takich problemów, może pomyśl jeszcze raz .)
— Voo,
3
@IgnacioSolerGarcia Ustanowienie konwencji dotyczącej poszczególnych projektów, działów lub firm nie jest lepsze niż organizowanie konwencji, o której wszyscy wiedzą, że nikt jej nie poinformuje. Ponadto zarządzanie pakietami lepiej wymusza przestrzeganie konwencji, ponieważ sprawia, że ​​przestrzeganie konwencji jest mniej pracochłonne niż jej łamanie. Jak już wspomniałem, zatwierdzam NuGet bezpośrednio i wywołuję go w skrypcie kompilacji, więc nie muszę go instalować. Kompiluję instalacje serwerów do absolutnego minimum.
— jpmc26
2
@ jpmc26 Imho Twoja pierwsza lista z numerami zyskałaby na podkreśleniu .
— Søren D. Ptæus
1
@ SørenD.Ptæus Gotowe.
— jpmc26
16

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:

  1. Znajdź, gdzie mogę uzyskać wszystkie zaktualizowane biblioteki
  2. Pobierz je i rozpakuj / zainstaluj
  3. Dodaj nowe wersje do kontroli źródła
  4. Ręcznie przejrzyj wszystkie odniesienia w naszych projektach i zaktualizuj je, aby wskazywały na nowe zespoły

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.

— 17 z 26
źródło
Zgadzam się, to jest punkt 2 pro. W każdym razie zmiana zależności jest czymś, co rzadko robimy (prawdopodobnie z powodu braku odpowiednich automatycznych testów regresji).
— Ignacio Soler Garcia
9
Aktualizowanie zależności jest czymś o wiele mniej bolesnym, jeśli robisz to regularnie.
— 17 z 26
1
Czy te testy są zautomatyzowane? Dokładnie ile czasu zajmuje im bieganie? Nawet jeśli uruchomienie pełnego zestawu testów zajmuje 24 godziny, nadal pozwala to aktualizować zależności co kilka dni z niewielkim minusem (chociaż prawdopodobnie nie robiłby tego tak często w praktyce). Nawet jeśli są one ręczne i nieuniknione, przy użyciu instalacji ręcznej możesz spędzić kilka dni na testowaniu, aby dowiedzieć się, że zawiodły, ponieważ przegapiłeś pewną zależność zależności, to po zainstalowaniu musisz zacząć od nowa, co by się nie zdarzyło za pomocą zarządzania pakietami ...
— Sean Burton
3
Czy nie potrzebujesz testów regresji dla nowych wersji oprogramowania? Po prostu zaktualizuj zależności, gdy już przeprowadzasz testy wersji.
— 17 z 26
4
„Nie mamy ich w pełni zautomatyzowanych, a narzędzie jest zbyt duże, aby to zrobić (może to potrwać miesiące testowania lub automatyzacji)” - jest twój duży problem. Testy te powinny były obowiązywać od samego początku. Problem nie polega na tym, że korzystanie z menedżerów pakietów nie daje żadnych korzyści. Problem polega na tym, że kontekst, w którym pracujesz, jest zbyt zepsuty na inne sposoby, abyś mógł się z nich cieszyć.
— Ant P
14

Nie potrzeba zewnętrznego narzędzia do zarządzania pakietami

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.

Kompilacja nie wymaga połączenia z Internetem

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ł

Szybsza kompilacja (bez sprawdzania pakietu)

To dość marginalne przyspieszenie, ale prawdopodobnie można to zrobić.

Prostsze środowiska (wymagana mniejsza wiedza)

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.

— Athos vk
źródło
Nie jest tak łatwo skonfigurować agenta kompilacji, aby instalował menedżera pakietów podczas kompilacji, przywracał zależności i tak dalej. Nic nie jest potrzebne z folderem lib.
— Ignacio Soler Garcia
4
Myślę, że to zależy od używanego języka / języków. W przypadku języków takich jak Ruby lub Rust zarządzanie pakietami jest tak dobrze zintegrowane, że korzystanie z niego jest całkowicie trywialne.
— Sean Burton,
Cóż, poleciłem to celowo, aby mieć szersze komentarze, ale mówię konkretnie o chmurze NuGet, C # i VSTS.
— Ignacio Soler Garcia
4
@Ignacio Niezależnie od tego, jakiego systemu kompilacji używasz, co nie sprawia, że ​​przywracanie NuGets jest całkowicie trywialne, powinno zostać natychmiast wyrzucone. Na szczęście VSTS sprawia, że ​​jest to tak proste, jak to tylko możliwe ( dokumentacja ): Istnieje zadanie przywracania NuGet, które wskazuje na plik rozwiązania i mówi, z jakich źródeł NuGet korzystać - w przypadku prostego projektu wystarczy samo użycie nuget.org(szablon domyślny powinien już skonfigurowane w ten sposób).
— Voo
3
@Ben RVM nie jest menedżerem pakietów. Menedżerem pakietów dla Ruby jest RubyGems. RVM zarządza wersjami samego Ruby, a do tego rbenv jest lepszy ...
— Sean Burton,
5

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.

  • Problemy z wersją biblioteki i zależnościami mogą być stratą czasu.

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.

  • Więcej struktury
  • Więcej przycinania bibliotek
  • Brak doraźnych ludzkich decyzji dotyczących bibliotek
— Joop Eggen
źródło
3

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:

  • Deweloper będzie musiał pobrać biblioteki (wymagany Internet)
  • Deweloper będzie musiał ręcznie sprawdzić dostępność nowszych wersji
  • ...

IMHO wymaga mniej wiedzy, ponieważ musisz nauczyć się korzystania z zewnętrznego narzędzia, a mniej bibliotek (tj. Zależności).

— FranMowinckel
źródło
4
Nawet w przypadku przestarzałych lub zmodyfikowanych bibliotek wszystkie menedżery pakietów, które do tej pory widziałem, oferują opcję przesyłania lokalnych zależności do lokalnego repozytorium. Ale ok, tutaj tracisz część doświadczenia „to działa automatycznie”.
— Hulk
@Hulk, jeśli jest to biblioteka typu open source, możesz (i prawdopodobnie powinna) po prostu opublikować swoją wersję, a tym samym pokazać ją menedżerowi pakietów. Albo przez przekazanie modyfikacji opiekunom, albo przez wydobycie własnego rozwidlenia biblioteki.
— leftaroundabout
Jeśli zmodyfikowałeś bibliotekę, której opiekun nie odpowiada na łatanie poczty, staje się problem z ustaleniem, jak skonfigurować menedżera pakietów, aby inne pakiety zależne od biblioteki mogły być również zadowolone ze zmodyfikowanej biblioteki.
— Damian Yerrick
1

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.

— val
źródło
-5

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.

— rackandboneman
źródło
4
To pytanie nie dotyczy bibliotek współdzielonych, ale zależności od folderu biblioteki.
— Ignacio Soler Garcia
1
To nie odpowiada na pytanie PO
— ezoterik
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.