Когда (не) целесообразно связывать зависимости с приложением?

Question

Краткие сведения

Недавно у меня был разговор с создателем фреймворка, от которого зависит одно из моих приложений.Во время этого разговора он упомянул как бы в сторону, что это упростило бы мою жизнь, если бы я просто объединил его фреймворк со своим приложением и предоставил конечному пользователю версию, которая, как я знал, соответствовала моему коду.Интуитивно я всегда старался избегать этого, и, фактически, я приложил все усилия, чтобы сегментировать свой собственный код таким образом, чтобы его части можно было распространять, не беря весь проект целиком (даже когда было очень мало шансов, что кто-нибудь когда-либо повторно воспользуется им).Однако, обдумав это в течение некоторого времени, я не смог придумать особенно веской причины почему Я делаю это.На самом деле, теперь, когда я подумал об этом, я вижу довольно убедительный аргумент в пользу объединения ВСЕ мои меньшие зависимости.Я составил список плюсов и минусов и надеюсь, что кто-нибудь сможет указать на все, чего мне не хватает.

Плюсы

• Согласованность версий означает упрощение тестирования и устранения неполадок.
• Приложение может охватить более широкую аудиторию, поскольку, по-видимому, требуется установить меньше компонентов.
• Небольшие изменения в зависимости могут быть более легко внесены ниже по потоку и доставлены вместе с приложением, вместо того, чтобы ждать, пока они просочатся в исходную кодовую базу.

Минусы

• Более сложный процесс упаковки, включающий в себя зависимости.
• Пользователь может в конечном итоге получить несколько копий зависимости от своего компьютера.
• Согласно ответу бортцмейера, существуют потенциальные проблемы с безопасностью, связанные с невозможностью обновления отдельных компонентов.

Примечания

Для справки, мое приложение написано на Python, и зависимости, на которые я ссылаюсь, являются "легкими", под которыми я подразумеваю небольшие и не очень часто используемые.(Таким образом, они существуют не на всех машинах и даже не во всех репозиториях.) И когда я говорю "упаковывать с" моим приложением, я имею в виду распространять в моем собственном дереве исходных текстов, а не устанавливать с помощью скрипта, который находится внутри моего пакета, чтобы не было никаких шансов на конфликтующие версии.Я также разрабатываю исключительно на Linux, так что проблем с установкой Windows, о которых стоит беспокоиться, нет.

Учитывая все сказанное, мне интересно услышать любые мысли и по более широкой (не зависящей от языка) проблеме упаковочных зависимостей.Есть ли что-то, чего мне не хватает, или это простое решение, которое я просто переоцениваю?

Добавление 1

Стоит отметить, что я также довольно чутко отношусь к потребностям упаковщиков, работающих ниже по течению.Я бы хотел, чтобы было как можно проще обернуть приложение в Deb или RPM, зависящие от конкретного дистрибутива.

Answer 1

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

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

Мне все равно, сколько копий библиотеки у меня на диске, главное, чтобы они не мешали друг другу.Дисковое пространство стоит очень, очень дешево.

Answer 2

Разве вы не можете просто положиться на определенную версию этих зависимостей?Например.в Python с инструменты настройки вы можете указать, какая именно версия ему нужна, или даже указать некоторые условия, такие как <= > и т.д.Это, конечно, относится только к Python и к конкретному менеджеру пакетов, но лично я бы всегда сначала старался не связывать все.Отправив его в виде Python egg, вы также автоматически установите все зависимости.

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

Некоторые сведения о яйцах см. этот мой пост.

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

Answer 3

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

Это означает, что объединение, как правило, является правильным решением.Если вы можете гарантировать, что ваше программное обеспечение будет устанавливаться плавно, без объединения зависимостей, и это потребует меньше усилий, то это может быть лучшим вариантом.Речь идет о том, что удовлетворяет ваших клиентов.

Answer 4

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

Имейте в виду, что в Linux зависимости автоматически подключаются к вам.Дело не в том, чтобы заставить пользователя получить их.Это уже сделано за тебя.

Для Windows не стесняйтесь связывать, там вы предоставлены сами себе.

Answer 5

Важный момент, похоже, был забыт из-за недостатков объединения библиотек / фреймворков / etc с приложением:обновления для системы безопасности.

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

Если вы не выполните связывание, системные администраторы просто обновят одну копию библиотеки и перезапустят зависящие приложения.

Если вы объедините, системные администраторы, вероятно, даже не знать они должны что-то модернизировать.

Таким образом, проблема с комплектацией заключается не в дисковом пространстве, а в риске распространения старых и опасных копий.

Answer 6

Просто мой опыт, отнеситесь к нему со всей серьезностью.

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

Из библиотек, которые я использовал в других, которые содержат зависимости от "общих" библиотек, неизменно получается, что мне требуется несколько версий общей библиотеки в моей системе.Относительная скорость обновления нишевых библиотек, которые я использую, просто не такая быстрая, в то время как обычные библиотеки обновляются гораздо чаще.Ад с версиями.

Но это если говорить в общих чертах.Если я могу помочь своему проекту и пользователям СЕЙЧАС, включив зависимость, я всегда смотрю на последующие последствия этого решения.Если я смогу с этим справиться, я смогу уверенно включить зависимость.

Как всегда, ваш пробег может варьироваться.

Answer 7

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

Answer 8

Остерегайтесь воспроизведения классического ада Windows DLL.Во что бы то ни стало сведите к минимуму количество зависимостей:в идеале, просто полагайтесь на свой язык и его фреймворк, ни на что другое, если можете.

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