Когда это (не) подходит для связывания зависимостей с приложением?

Резюме

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

Pros

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

против

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

Примечания

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

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

Добавление 1

Стоит упомянуть, что я также очень чувствителен к потребностям пакетов вниз по потоку. Я хотел бы, чтобы это было максимально простым, чтобы обернуть приложение в Deb-RPM, специфичном для распространения.

Ответ 1

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

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

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

Ответ 2

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

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

Для некоторого введения в яйца см. этот пост моей.

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

Ответ 3

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

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

Ответ 4

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

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

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

Ответ 5

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

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

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

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

Таким образом, проблема с набором не является дисковым пространством, это риск позволить старым и опасным копиям.

Ответ 6

Только мой опыт, возьмите его с солью.

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

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

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

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

Ответ 7

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

Ответ 8

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

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