Навіщо віддавати перевагу менеджеру пакунків над папкою бібліотеки?

Коли я думаю про плюси і мінуси статичної папки бібліотеки та менеджера пакунків, я відчуваю, що папка бібліотеки - це кращий підхід.

Плюси, які я бачу з папкою бібліотеки:

1. Немає необхідності у зовнішньому інструменті для управління пакетами.
2. Не потрібно з'єднання з Інтернетом будувати.
3. Швидше складання (відсутність перевірки пакета).
4. Простіше середовище (менше знань потрібно).

Плюси, які я бачу з менеджером пакунків:

1. Допомагає зі складними деревами залежностей (і цим можна керувати, завантажуючи залежність разом із усіма її залежностями).
2. Допомагає перевірити, чи є нова версія.

Здається, галузь вирішила піти шляхом менеджера пакунків майже для всього побудованого сьогодні. Отже, чого я пропускаю?

Важливий момент, який не вистачає в інших відповідях:

Використовувати менеджер пакунків означає наявність конфігурації, яка вказує, які версії бібліотеки ви використовуєте, і гарантує, що інформація конфігурації насправді правильна.

Знаючи, які бібліотеки ви використовуєте та яку версію, дуже важливо, якщо ви:

• необхідність оновлення бібліотеки через критичну помилку / безпеку;
• або просто потрібно перевірити, чи впливає на вас оголошена безпека.

Крім того, коли ви фактично робите оновлення, менеджер пакунків (як правило) гарантує, що будь-які перехідні залежності оновлюються у міру необхідності.

У той час як з libпапкою, ви просто купа (можливо бінарних, і , можливо , модифікованими) файлів, і ви повинні вгадати , звідки вони прийшли і скільки разів вони (або довіряти деякі README, які можуть або не можуть бути правильними ).

Щоб вирішити інші питання:

Немає потреби в зовнішньому інструменті для управління пакетами.

Правда, але а) як розробник програмного забезпечення вам все-таки потрібно встановити набір інструментів, тому один більше, як правило, не має значення; б) зазвичай в одному полі є лише один або кілька менеджерів пакетів (Maven / Gradle для Java, npm для JS / TypeScript тощо), тому не так, як вам потрібно встановити десятки.

Не потрібно з'єднання з Інтернетом будувати.

Усі менеджери пакунків, яких я знаю, працюють в режимі офлайн, після завантаження необхідних залежностей (що може статися відразу після завантаження самого проекту).

Швидше складання (відсутність перевірки пакета).

Можливо, це правда, але здається, що перевірка пакету в автономному режимі навряд чи займе значну кількість часу (це лише порівняння деяких номерів версій). Онлайн перевірка може зайняти деякий час, але це може бути відключений , якщо необхідно (якщо це навіть за замовчуванням - Maven, наприклад , ніколи не перевіряє наявність оновлень для версій випуску).

Простіші середовища (менше знань потрібно).

Щоправда, але, як пояснено вище, libпапка також вимагає знань. Крім того, як пояснено вище, ви, ймовірно, працюєте лише з кількома менеджерами різних пакетів, про які ви вже будете знати.

Плюси папки lib швидко зникають після переходу від розробки невеликих масштабів до більшої роботи.

Наприклад, "користь" від того, що не потрібен зовнішній інструмент, переслідується роботою, необхідною для керування вашими залежностями вручну, тому інструментом ви будете користуватися вами (у більш ніж одному сенсі світу).

Вам не потрібно підключення до Інтернету для менеджера пакунків. Можна використовувати локальні сховища.

Швидше складання може бути правдивим, але навряд чи те, що повинно визначати, використовувати менеджер пакунків чи ні. Адже ми не говоримо про різницю величин, і це теж залежить від вашої конфігурації. Ви можете легко зробити повільну збірку за допомогою менеджера пакунків, але це в основному саботаж.

Простіші середовища (потрібно менше знань)? Знову ж таки, в невеликих масштабах розробка безумовно можлива. Можливо, ви зможете повністю утримати проект у голові, аж до кожної з кількох використовуваних бібліотек. Додайте простий скрипт makefile / інший збір, і ви отримаєте повний пакет.

Але це не робить середовища простіше, він працює тільки в простих умовах. При розробці масштабних масштабів ви будете раді, що замість користувацьких рішень використовуєте стандартні інструменти. Зрештою, вам доведеться це лише навчитися раз (і коли менеджер пакунків du jour замінить новою класною річчю, ви також повинні це навчитися).

Вам не вистачає багатьох переваг менеджерів пакетів.

1. Менеджери пакунків дозволяють вам уникнути перевірки великих (декількох мегабайт або більше) бінарних файлів у керуванні джерелами. Це анафема багатьом інструментам контролю джерел, одна з них є поширеною суглобом. Кілька місяців тому у нас було сховане обмеження розміру Bit Bucket, оскільки розробники перевіряли в CocoaPods. Інший проект уже був на півдорозі, коли ми перейшли з SVN, тому що ми перевіряли всі наші бінарні файли (і не використовували NuGet). Оскільки менеджери пакунків завантажуватимуть пакети влітку для кожного розробника, вони усувають необхідність перевірки цих бінарних файлів у.
2. Вони запобігають змішуванню несумісних файлів / бібліотек. Папки можуть містити змішані версії файлів бібліотеки, якщо хтось не очистить їх належним чином під час оновлення. Я бачив випадок, коли половину двійкових файлів у папці було оновлено, що призводило до дуже дивних помилок. (Це навіть не вийшло з ладу!) Ми розібралися в проблемі буквально місяцями (не людиною годин, просто загальним часом). Дозволяючи менеджеру пакунків контролювати всю папку, ви не можете отримати змішані версії; ви забезпечуєте послідовність. Вони також значно ускладнюють використання несумісних залежностей , автоматично оновлюючи все разом, встановлюючи різні версії, де це потрібно, або навіть просто викидаючи попередження або помилки при спробі використання несумісних версій бібліотек.
3. Вони встановлюють спільну конвенцію щодо управління бібліотеками. Коли нові розробники натрапляють на ваш проект, команду, компанію тощо, вони, ймовірно, знають конвенції менеджера пакунків. Це означає, що їм не потрібно витрачати час на з'ясування тонких деталей, якими керуються бібліотеки у вашій кодовій базі.
4. Вони дають вам стандартний спосіб версії та розповсюдження власних залежностей та файлів, які не належать до вашого сховища. Я навіть особисто використовував їх для великих великих статичних файлів даних, необхідних моїй програмі, тому він добре працює для редагування речей, крім бінарного коду.
5. Деякі менеджери пакунків надають додаткові функції під час встановлення. NuGet додасть файли залежностей та файлів вмісту у ваш файл csproj і навіть може додати конфігураційні елементи до конфігураційного файлу.
6. Файли списків пакунків документують версії ваших бібліотек в одному централізованому місці. Мені не потрібно клацати правою кнопкою миші DLL і дивитися на номер версії, щоб зрозуміти, яку версію бібліотеки я використовую. У Python автор бібліотеки, можливо, навіть не включив номер версії до файлів py, тому я, можливо, навіть не зможу сказати версію бібліотеки з них.
7. Вони відштовхують машину від встановлення залежностей. Менеджери пакунків пропонують звичайний спосіб встановлення залежностей без глобального інсталятора . Коли ваші параметри - це папка lib та глобальна установка, багато розробників бібліотек вирішать запропонувати свої бібліотеки первинними як глобальні установки, а не як завантажувані бінарні файли, які вам доведеться налаштувати самостійно. (Історія MS це демонструє. Це також стосується багатьох бібліотек в Linux.) Це насправді ускладнює керування кількома проектами, оскільки у вас можуть бути проекти з конфліктними версіями, і деякі розробники, безумовно, виберуть, здавалося б, простішу глобальну установку через наявність власної ліб реж.
8. Вони мають тенденцію до централізації хостингу та дистрибуції. Вам більше не доведеться залежати від веб-сайту цієї випадкової бібліотеки. Якщо вони припиняють свою діяльність, на сайті успішного менеджера пакунків все ще є будь-яка завантажена версія. Розробникам також не потрібно шукати багато веб-сайтів лише для завантаження нових бібліотек; у них є місце, де потрібно спочатку подивитися і навіть переглянути різні варіанти. Так само простіше віддзеркалювати пакети, організовані стандартним способом, ніж вручну розміщувати копії всього із спеціальних веб-сайтів.

Ви також завищуєте цінність своїх "переваг".

1. Немає потреби в зовнішньому інструменті для управління пакетами.

   "Зовнішній" до чого? Я перевіряю виконуваний файл NuGet у свої сховища. Це єдиний бінарний файл, з яким я добре себе зареєстрував, оскільки він невеликий і означає, що мені не потрібно перевіряти жодні інші бінарні файли.

   pip не створює проблем на цьому фронті, оскільки він за замовчуванням в комплекті з Python, а несумісні зміни зламання та назад дуже рідкісні. Ви не збираєтеся розробляти код Python, без того, щоб Python був встановлений зовні у вашому проекті.

   На той час, коли вони досягли широкого поширення, менеджери пакетів, як правило, дуже стабільні. Ви не можете піти без якогось глобально встановленого інструментарію для більшості проектів, а єдиний менеджер пакунків - це досить легка вага. Зазвичай це не набагато громіздкіше, ніж встановлення мови виконання.

2. Не потрібно з'єднання з Інтернетом будувати.

   Я не можу підключитися до своєї бази даних без підключення до мережі. Якщо база даних розміщена в Amazon, мені все одно потрібне повне підключення до Інтернету. Мені потрібне підключення до Інтернету, щоб натиснути та перетягнути зміни через контроль джерела; сервер збирання не може перевірити код для побудови без якогось мережевого підключення. Ви не можете надсилати та отримувати електронну пошту без одного. Ви не можете завантажити бібліотеки, щоб помістити їх у свою папку lib! Постійний розвиток без підключення до Інтернету практично не чутий. У деяких рідкісних випадках, коли це необхідно, ви можете впоратися з цим, завантаживши пакети в місце, яке може споживати менеджер пакунків. (Я знаю, що NuGet і pip із задоволенням витягуються з простої папки або мережевого накопичувача; я підозрюю, що і більшість інших може.)

3. Швидше складання (відсутність перевірки пакета).

   30 секунд під час автоматизованої збірки та 5 секунд під час побудови локальних розробників - це хороша компроміс за ті переваги, які я окреслив вище. Це тривіальні часові рамки, які зазвичай навіть не варто розглядати порівняно з проблемами, які вирішують переваги.

4. Простіші середовища (менше знань потрібно).

   Один із інструментів для управління пакунками проти нічого для управління бібліотекою все-таки не є справжнім порівнянням Без цього інструменту ви повинні дізнатися, який користувальницький процес використовується в проектікерувати своїми бібліотеками. Це означає, що ви ніколи не впевнені, чи застосовуються ваші існуючі знання до будь-якого нового проекту, до якого ви підходите. Вам доведеться мати справу з тим, з ким би хтось придумав, або скласти свій. Це може бути каталог, що містить усі бібліотеки, або це може бути щось набагато дивніше. Можливо, щоб уникнути перевірки бібліотек, хтось виклав їх на мережевий диск, і єдиним індикатором версії є назва папки. Як це чи глобальна установка насправді краща? Для порівняння, менеджер пакунків дає вам чітку умову, яка застосовуватиметься до більшості проектів, з якими ви стикаєтесь.

Загальна тема полягає в тому, що вони забезпечують узгодженість, документацію та особливості не лише в межах проектів, але навіть у межах усіх. Це спрощує життя кожного.

Нещодавно перетворивши наш продукт з використання завантажених вручну бібліотек в автоматичне управління пакетами з Nuget, я можу сказати, що використання менеджера пакунків має величезні переваги.

Наш продукт реалізовується в 27 проектах C #, що за сучасними мірками порівняно мало. Деякі з наших сторонніх залежностей мають десятки зборів.

До Nuget, якби я хотів оновити всі наші залежності до останньої версії, я повинен був би:

1. Простежте, де я міг би отримати всі оновлені бібліотеки
2. Завантажте їх і розпакуйте / встановіть
3. Додайте нові версії до джерела управління
4. Вручну перегляньте всі посилання на наші проекти та оновіть їх, щоб вказати на нові збірки

З 27 проектами і десятками зборів залежностей цей процес був дуже схильний до помилок і може зайняти години.

Тепер, коли ми перейшли на використання Nuget, для мене це зроблено однією командою.

Немає необхідності в зовнішньому інструменті для управління пакетами

Це якась нетипова справа? Якщо я використовую менеджер пакунків, мені не потрібно мати папки lib. Я також не повинен сам керувати пакетами.

Не потрібно з'єднання з Інтернетом будувати

Окрім того, що сьогодні немає підключення до Інтернету під час розробки є дещо рідкісним (можливо, за винятком транзиту), гідний менеджер пакунків не повинен вимагати, щоб у вас була версія останньої версії для створення програми. Це може скаржитися, але немає причин не будувати з уже встановленою версією

Швидше складання (відсутність перевірки пакета)

Це досить маргінальна швидкість, але ви, безперечно, можете зробити для цього крапку.

Простіші середовища (менше знань, необхідних)

Більшість менеджерів пакунків настільки прості в наші дні, що навряд чи варто намагатися їх обійти, роблячи це. При бажанні є навіть візуальні клієнти. Вони насправді приховують багато того, що відбувається.

Менеджери пакетів також дозволяють ділитися цими пакетами між різними проектами. Якщо 5 моїх проектів використовують одну і ту ж версію Boost, не потрібно дублювати це для кожного проекту. Особливо це стосується складних дерев залежностей, про які ви говорите.

За допомогою папки lib ви керуєте пакетами лише для цього проекту, тоді як менеджер пакунків дозволяє зробити це для всього середовища розробки одним інструментом.

Це різниця між просто використанням бібліотек (каталог lib) та їх використанням, підтримкою метаінформації (менеджер пакунків) . Така метаінформація стосується номерів версій, (перехідних) залежностей між бібліотеками тощо.

Обговорення пекла DLL, сумісності бібліотек, системи модулів java, OSGi тощо повинні принаймні бути достатньо переконливими щодо того, що варто мати певну форму управління залежностями.

• Проблеми з версією бібліотеки та залежністю можуть затратити час.

Також є користь спільного (локального) сховища, тому для декількох проектів не потрібно підтримувати копії імпортованих файлів. Якщо є проект з 20 підмодулями, то деякі з цих модулів мають 40 непарних залежностей.

• Більше структури
• Більше обрізки бібліотек
• Немає спеціальних людських рішень щодо бібліотек

Є деякі випадки, коли папка lib може знадобитися, наприклад, при роботі із застарілими бібліотеками (версія її більше не підтримується / доступна), локально модифікована версія бібліотеки, ...

Але для всього іншого, це як розробник, який бере на себе роль менеджера пакунків:

• Розробнику доведеться завантажити бібліотеки (необхідний Інтернет)
• Розробнику доведеться перевіряти нові версії вручну
• ...

І ІМХО, знадобиться менше знань, тому що ви повинні дізнатися про використання зовнішнього інструменту, але менше про бібліотеки (тобто залежності).

Є ще одна проблема, не охоплена іншими питаннями: спільний доступ до програм.

Скажімо, у вас є два пакети, що будують одну бібліотеку. У кращому випадку не буде жодних конфліктів, але той самий простір на жорсткому диску / SSD, який використовується двічі. У гіршому випадку будуть конфлікти варіо, як і версії.

Якщо ви використовуєте менеджер пакунків, він встановить бібліотеку лише один раз (за версією) і вже надасть шлях до неї.

PS: звичайно, вам потрібен динамічний зв'язок (або подібна функція на вашій мові), щоб отримати цей профі.

Однією з основних причин того, що спільні бібліотеки вважалися предметом прогресу в системах Unix і Windows 90-х років, - це те, як вони могли знизити використання оперативної пам’яті при завантаженні декількох програм, що використовують один і той же набір бібліотек. Простір коду потрібно виділити лише ONCE на точну бібліотеку та версію цієї бібліотеки , залишилось лише використання пам’яті для кожного примірника для статичних змінних.

Багато операційних систем реалізують спільні бібліотеки таким чином, що залежать від механізмів, таких як unix mmap () api - що означає, що бібліотеці буде потрібно не тільки та сама версія, а й саме той самий ФАЙЛ. Це просто неможливо повною мірою використати для програми, яка постачає власний набір бібліотек.

Зважаючи на те, що пам'ять набагато дешевша, а бібліотечні версії потребують більш різноманітних, ніж у 90-х, цей аргумент не має такої ваги сьогодні.