Почему менеджер пакетов предпочитает библиотеку?

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

Плюсы, которые я вижу с папкой библиотеки:

1. Нет необходимости во внешнем инструменте для управления пакетами.
2. Нет подключения к интернету требуется построить.
3. Быстрая сборка (без проверки пакетов).
4. Более простая среда (требуется меньше знаний).

Плюсы я вижу с менеджером пакетов:

1. Помогает со сложными деревьями зависимостей (и этим можно управлять, загружая зависимость вместе со всеми ее зависимостями).
2. Помогает проверить наличие новой версии.

Похоже, что индустрия решила пойти по пути менеджера пакетов практически для всего, что было построено сегодня. Итак, что мне не хватает?

В других ответах отсутствует важный момент:

Использование диспетчера пакетов означает наличие конфигурации, которая указывает, какие версии библиотек вы используете, и обеспечивает правильность информации о конфигурации.

Знание того, какие библиотеки вы используете и какую версию, очень важно, если вы:

• необходимо обновить библиотеку из-за критической ошибки / дыры в безопасности;
• или просто нужно проверить, влияет ли объявленная дыра в безопасности на вас.

Кроме того, когда вы действительно выполняете обновление, менеджер пакетов (обычно) следит за тем, чтобы любые транзитивные зависимости обновлялись по мере необходимости.

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

Для решения других ваших вопросов:

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

Да, но а) как разработчик программного обеспечения, вам все равно нужно устанавливать множество инструментов, поэтому обычно еще один не имеет значения, и б) обычно в каждом поле есть только один или несколько менеджеров пакетов (Maven / Gradle для Java, npm для JS / TypeScript и т. д.), поэтому вам не нужно устанавливать десятки из них.

Нет подключения к интернету требуется построить.

Все менеджеры пакетов, которых я знаю, работают в автономном режиме, как только они загрузили необходимые зависимости (что может произойти сразу после загрузки самого проекта).

Быстрая сборка (без проверки пакетов).

Возможно, это правда, но кажется маловероятным, что автономная проверка пакетов займет значительное время (это просто сравнение некоторых номеров версий). Проверка в режиме онлайн может занять некоторое время, но при желании ее можно отключить (если она даже включена по умолчанию - например, Maven никогда не проверяет наличие обновлений для версий выпуска).

Более простые условия (требуется меньше знаний).

Правда, но, как объяснено выше, libпапка также требует знаний. Кроме того, как объяснено выше, вы, вероятно, будете работать только с несколькими менеджерами пакетов, о которых вы уже знаете.

Плюсы папки lib быстро исчезают после перехода от мелкомасштабной разработки к более крупной работе.

Например, «преимущество» отсутствия необходимости использования внешнего инструмента перевешивается работой, необходимой для ручного управления вашими зависимостями, поэтому этот инструмент будет вам (в нескольких смыслах мира).

Вам не нужно подключение к интернету для менеджера пакетов. Вы можете использовать локальные репозитории.

Быстрая сборка может быть правдой, но вряд ли это что-то, что должно определять, использовать менеджер пакетов или нет. В конце концов, мы не говорим о разнице величин, и это тоже зависит от вашей конфигурации. Вы можете легко сделать медленную сборку, используя менеджер пакетов, но это в основном саботаж.

Более простые условия (требуется меньше знаний)? Опять же, в малом масштабе развитие определенно возможно. Возможно, вы сможете полностью удержать проект в своей голове, вплоть до каждой из немногих используемых библиотек. Добавьте простой make-файл / другой скрипт сборки, и вы получите полный пакет.

Но это не делает среду проще, она работает только в простых средах. В более масштабных разработках вы будете рады, что вместо стандартных решений вы используете стандартные инструменты. В конце концов, вам нужно выучить его только один раз (и когда менеджер пакетов du jour заменяется новой классной вещью, вы должны также изучить это).

Вам не хватает многих преимуществ менеджеров пакетов.

1. Менеджеры пакетов позволяют избежать проверки больших (несколько мегабайт или более) двоичных файлов в системе контроля версий. Это является анафемой для многих инструментов контроля версий, одним из которых является распространяющийся git. У нас был репозиторий, ограничивающий размеры Bit Bucket пару месяцев назад, потому что разработчики проверяли в CocoaPods. Другой проект был уже на полпути, когда мы мигрировали из SVN, потому что мы проверяли все наши двоичные файлы lib (и не использовали NuGet). Поскольку менеджеры пакетов будут загружать пакеты на лету для каждого разработчика, они устраняют необходимость проверять эти двоичные файлы.
2. Они предотвращают смешивание несовместимых файлов / библиотек. Папки могут содержать смешанные версии файлов библиотеки, если кто-то не очистит их должным образом во время обновления. Я видел случай, когда половина двоичных файлов в папке была обновлена, что привело к очень странным ошибкам. (Он даже не разбился!) Нам потребовались буквально месяцы (не человеческие часы, а просто общее время), чтобы выяснить проблему. Позволяя менеджеру пакетов контролировать всю папку, вы не можете получить смешанные версии; Вы гарантируете последовательность. Они также значительно усложняют использование несовместимых зависимостей , автоматически обновляя все вместе, устанавливая различные версии, где это необходимо, или даже просто выдавая предупреждения или ошибки при попытке использовать несовместимые версии библиотек.
3. Они устанавливают общее соглашение для управления библиотеками. Когда новые разработчики приходят в ваш проект, команду, компанию и т. Д., Они, вероятно, знают соглашения менеджера пакетов. Это означает, что им не нужно тратить время на выяснение мелких деталей управления библиотеками в вашей кодовой базе.
4. Они предоставляют вам стандартный способ создания версий и распространения ваших собственных зависимостей и файлов, которые не принадлежат вашему хранилищу. Я даже лично использовал их для некоторых больших статических файлов данных, которые требовались моему приложению, поэтому он хорошо работает для управления версиями, помимо двоичного кода.
5. Некоторые менеджеры пакетов предоставляют дополнительные функции во время установки. NuGet добавит зависимости и файлы содержимого в ваш файл csproj и даже может добавить элементы конфигурации в файл конфигурации.
6. Их файлы списка пакетов документируют версии ваших библиотек в едином централизованном месте. Мне не нужно щелкать правой кнопкой мыши на DLL и смотреть номер версии, чтобы выяснить, какую версию библиотеки я использую. В Python автор библиотеки, возможно, даже не включил номер версии в py-файлы, поэтому я даже не смогу узнать версию библиотеки из них.
7. Они препятствуют общезаводской установке зависимостей. Менеджеры пакетов предоставляют обычный способ установки зависимостей без глобального установщика . Когда вашими опциями являются папка lib и глобальная установка, многие разработчики библиотек предпочтут предлагать свои библиотеки в основном как глобальные установки, а не как загружаемые двоичные файлы, которые вы должны настроить самостоятельно. (История MS демонстрирует это. Это также относится ко многим библиотекам в Linux.) Это на самом деле делает управление несколькими проектами более сложным, поскольку у вас могут быть проекты с конфликтующими версиями, и некоторые разработчики, безусловно, предпочтут, казалось бы, более простую глобальную установку, чем имея собственную библиотеку lib. реж.
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-х годов, заключалась в том, что они могли снизить использование ОЗУ при загрузке нескольких программ, использующих один и тот же набор библиотек. Пространство кода должно быть выделено ОДИН РАЗ для каждой конкретной библиотеки и версии этой библиотеки , единственное использование памяти для каждого экземпляра остается для статических переменных.

Многие операционные системы реализуют разделяемые библиотеки таким образом, что зависит от таких механизмов, как unix mmap () api, что подразумевает, что библиотека должна быть не только одной и той же версии, но фактически того же ФАЙЛА. Это просто невозможно в полной мере использовать для программы, которая поставляется с собственным набором библиотек.

Учитывая, что память намного дешевле, а версии библиотек нуждались в большем разнообразии, чем в 90-е годы, этот аргумент сегодня не имеет большого веса.