Когда я думаю о плюсах и минусах папки статической библиотеки и менеджера пакетов, я чувствую, что папка библиотеки - лучший подход.
Плюсы, которые я вижу с папкой библиотеки:
- Нет необходимости во внешнем инструменте для управления пакетами.
- Нет подключения к интернету требуется построить.
- Быстрая сборка (без проверки пакетов).
- Более простая среда (требуется меньше знаний).
Плюсы я вижу с менеджером пакетов:
- Помогает со сложными деревьями зависимостей (и этим можно управлять, загружая зависимость вместе со всеми ее зависимостями).
- Помогает проверить наличие новой версии.
Похоже, что индустрия решила пойти по пути менеджера пакетов практически для всего, что было построено сегодня. Итак, что мне не хватает?
packages
dependency-management
package-managers
Игнасио Солер Гарсия
источник
источник
Ответы:
В других ответах отсутствует важный момент:
Использование диспетчера пакетов означает наличие конфигурации, которая указывает, какие версии библиотек вы используете, и обеспечивает правильность информации о конфигурации.
Знание того, какие библиотеки вы используете и какую версию, очень важно, если вы:
Кроме того, когда вы действительно выполняете обновление, менеджер пакетов (обычно) следит за тем, чтобы любые транзитивные зависимости обновлялись по мере необходимости.
Принимая во внимание, что с
libпапкой у вас просто есть куча (возможно, двоичных и, возможно, измененных) файлов, и вам нужно будет угадать, откуда они и какую версию они представляют (или доверять некоторому README, что может быть или не быть правильным ).Для решения других ваших вопросов:
Да, но а) как разработчик программного обеспечения, вам все равно нужно устанавливать множество инструментов, поэтому обычно еще один не имеет значения, и б) обычно в каждом поле есть только один или несколько менеджеров пакетов (Maven / Gradle для Java, npm для JS / TypeScript и т. д.), поэтому вам не нужно устанавливать десятки из них.
Все менеджеры пакетов, которых я знаю, работают в автономном режиме, как только они загрузили необходимые зависимости (что может произойти сразу после загрузки самого проекта).
Возможно, это правда, но кажется маловероятным, что автономная проверка пакетов займет значительное время (это просто сравнение некоторых номеров версий). Проверка в режиме онлайн может занять некоторое время, но при желании ее можно отключить (если она даже включена по умолчанию - например, Maven никогда не проверяет наличие обновлений для версий выпуска).
Правда, но, как объяснено выше,
libпапка также требует знаний. Кроме того, как объяснено выше, вы, вероятно, будете работать только с несколькими менеджерами пакетов, о которых вы уже знаете.источник
Плюсы папки lib быстро исчезают после перехода от мелкомасштабной разработки к более крупной работе.
Например, «преимущество» отсутствия необходимости использования внешнего инструмента перевешивается работой, необходимой для ручного управления вашими зависимостями, поэтому этот инструмент будет вам (в нескольких смыслах мира).
Вам не нужно подключение к интернету для менеджера пакетов. Вы можете использовать локальные репозитории.
Быстрая сборка может быть правдой, но вряд ли это что-то, что должно определять, использовать менеджер пакетов или нет. В конце концов, мы не говорим о разнице величин, и это тоже зависит от вашей конфигурации. Вы можете легко сделать медленную сборку, используя менеджер пакетов, но это в основном саботаж.
Более простые условия (требуется меньше знаний)? Опять же, в малом масштабе развитие определенно возможно. Возможно, вы сможете полностью удержать проект в своей голове, вплоть до каждой из немногих используемых библиотек. Добавьте простой make-файл / другой скрипт сборки, и вы получите полный пакет.
Но это не делает среду проще, она работает только в простых средах. В более масштабных разработках вы будете рады, что вместо стандартных решений вы используете стандартные инструменты. В конце концов, вам нужно выучить его только один раз (и когда менеджер пакетов du jour заменяется новой классной вещью, вы должны также изучить это).
источник
blah install libfoo. А затем умножьте это на, скажем, 5 зависимостей.Вам не хватает многих преимуществ менеджеров пакетов.
Вы также преувеличиваете ценность своих «преимуществ».
«Внешний» к чему? Я проверяю исполняемый файл NuGet в своих репозиториях. Это единственный двоичный файл, в котором я чувствую себя хорошо, регистрируясь, так как он маленький и означает, что мне не нужно проверять другие двоичные файлы.
pip не создает проблем на этом фронте, так как теперь он связан с Python по умолчанию, а критические изменения и обратные несовместимые изменения встречаются крайне редко. В любом случае, вы не собираетесь разрабатывать код Python без внешней установки Python в ваш проект.
К тому времени, когда они достигают широкого распространения, менеджеры пакетов, как правило, становятся очень стабильными. Вы не можете обойтись без каких- либо глобально установленных инструментов для большинства проектов, и один менеджер пакетов является довольно легким требованием. Обычно это не намного более громоздко, чем установка языковой среды выполнения.
Я не могу подключиться к своей базе данных без сетевого подключения. Если база данных размещена на Amazon, мне все равно нужно полное интернет-соединение. Мне нужно подключение к Интернету, чтобы протолкнуть изменения через систему контроля версий; Сервер сборки также не может извлекать код для сборки без какого-либо сетевого подключения. Вы не можете отправлять или получать электронную почту без него. Вы не можете скачать библиотеки, чтобы поместить их в папку lib без них! Постоянно развиваться без подключения к интернету практически неслыханно. В некоторых редких случаях, когда это необходимо, вы можете решить эту проблему, загрузив пакеты в место, которое может использовать менеджер пакетов. (Я знаю, что NuGet и pip очень рады вытащить из простой папки или сетевого диска; я подозреваю, что большинство других также могут.)
30 секунд во время автоматической сборки и 5 секунд во время локальной сборки - хороший компромисс с преимуществами, которые я описал выше. Это тривиальные временные рамки, которые, как правило, даже не стоит рассматривать в сравнении с проблемами, которые решают преимущества.
Во всяком случае, один инструмент для управления пакетами, а не для управления библиотеками, на самом деле не является честным сравнением. Без инструмента вы должны изучить любой пользовательский процесс, который использует проектуправлять своими библиотеками. Это означает, что вы никогда не уверены, применимы ли ваши знания к любому новому проекту, к которому вы подходите. Вы должны будете иметь дело с любым подходом сборной солянки, или придумать свой собственный. Это может быть каталог, содержащий все библиотеки, или что-то более странное. Может быть, чтобы избежать проверки библиотек, кто-то поместил их все на сетевой диск, и единственным индикатором версии является имя папки. Как это или глобальная установка действительно лучше? Для сравнения, менеджер пакетов дает вам четкое соглашение, которое будет применяться ко всем встречающимся проектам.
Общей темой является то, что они обеспечивают согласованность, документацию и функции не только внутри проектов, но даже между ними. Это упрощает жизнь каждого.
источник
Недавно, превратив наш продукт из загружаемых вручную библиотек в автоматическое управление пакетами с помощью Nuget, я могу сказать, что использование менеджера пакетов имеет огромные преимущества.
Наш продукт реализован в 27 проектах C #, что относительно мало по сегодняшним стандартам. Некоторые из наших сторонних зависимостей имеют десятки сборок.
До Nuget, если бы я хотел обновить все наши зависимости до последней версии, мне пришлось бы:
С 27 проектами и десятками сборок зависимостей этот процесс был очень подвержен ошибкам и мог занимать часы.
Теперь, когда мы обновились до использования Nuget, все это сделано для меня одной командой.
источник
Это что-то не так, не так ли? Если я использую менеджер пакетов, мне не нужна папка lib. Я также не должен управлять пакетами самостоятельно.
Помимо того, что в настоящее время нет подключения к Интернету, в то время как разработка является довольно редкой (возможно, за исключением транзита), приличный менеджер пакетов не должен требовать наличия последней версии для сборки приложения. Может жаловаться, но нет причин не собираться с версией, которую он уже установил
Это довольно незначительный спидбуст, но вы, возможно, можете сказать об этом.
В наши дни большинство менеджеров пакетов настолько просты, что вряд ли стоит пытаться обойти их, делая это. Есть даже визуальные клиенты, если хотите. Они на самом деле скрывают большую часть происходящего.
Менеджеры пакетов также позволяют вам делиться этими пакетами между различными проектами. Если 5 моих проектов используют одну и ту же версию Boost, нет необходимости дублировать это для каждого проекта. Это особенно верно для сложных деревьев зависимостей, о которых вы говорите.
С папкой lib вы управляете пакетами только для этого проекта, а менеджер пакетов позволяет вам делать это для всей среды разработки с помощью одного инструмента.
источник
nuget.orgбудет в порядке (шаблон по умолчанию должен уже настроен таким образом).Это разница между просто использованием библиотек (каталог lib) и их использованием, поддерживая метаинформацию (менеджер пакетов) . Такая метаинформация касается номеров версий, (транзитивных) зависимостей между библиотеками и тому подобным.
Дискуссии об аде DLL, совместимости библиотек, системе java-модулей, OSGi и т. Д. Должны, по крайней мере, быть достаточно убедительными в некоторой ценности наличия некоторой формы управления зависимостями.
Также есть преимущество общего (локального) хранилища, поэтому нескольким проектам не нужно хранить копии импортированных библиотек. Если у вас есть проект с 20 подмодулями, то некоторые из этих модулей имеют 40 нечетных зависимостей.
источник
В некоторых случаях может потребоваться папка lib, например, при работе с устаревшими библиотеками (версия которых больше не поддерживается / недоступна), локально измененной версией библиотеки, ...
Но для всего остального это похоже на разработчика, принимающего на себя роль менеджера пакетов:
И ИМХО, требуется меньше знаний, потому что вы должны узнать об использовании внешнего инструмента, но меньше о библиотеках (то есть зависимостях).
источник
Есть еще одна проблема, не затронутая другими вопросами: совместное использование депов.
Допустим, у вас есть два пакета, создающих одну и ту же библиотеку. В лучшем случае не будет никаких конфликтов, но одно и то же место на жестком диске / SSD используется дважды. В худшем случае будут конфликты вариаций, например версии.
Если вы используете менеджер пакетов, он установит библиотеку только один раз (для каждой версии) и уже предоставит путь к ней.
PS: конечно, вам нужна динамическая связь (или похожая функция на вашем языке), чтобы получить этого профессионала.
источник
Одна из основных причин, по которой разделяемые библиотеки считались прогрессом в системах Unix и Windows 90-х годов, заключалась в том, что они могли снизить использование ОЗУ при загрузке нескольких программ, использующих один и тот же набор библиотек. Пространство кода должно быть выделено ОДИН РАЗ для каждой конкретной библиотеки и версии этой библиотеки , единственное использование памяти для каждого экземпляра остается для статических переменных.
Многие операционные системы реализуют разделяемые библиотеки таким образом, что зависит от таких механизмов, как unix mmap () api, что подразумевает, что библиотека должна быть не только одной и той же версии, но фактически того же ФАЙЛА. Это просто невозможно в полной мере использовать для программы, которая поставляется с собственным набором библиотек.
Учитывая, что память намного дешевле, а версии библиотек нуждались в большем разнообразии, чем в 90-е годы, этот аргумент сегодня не имеет большого веса.
источник