Когда не уместно связать зависимости приложением?

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

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

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

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

Поскольку некоторое введение в яйца видит это мое сообщение.

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

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

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

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

Просто мой опыт, возьмите его с мелкой частицей соли.

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

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

Но это говорит в общем. Если я могу помочь своему проекту и пользователям ТЕПЕРЬ путем слияния зависимости, я всегда смотрю на нисходящий поток и эффекты более поздней даты того решения. Если я могу управлять им, я могу уверенно включать зависимость.

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

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

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

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

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

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

Так, проблемой со связыванием не является дисковое пространство, это - риск разрешения старым и опасным копиям вокруг.

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

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