Когда уместно связывать зависимости с приложением? - PullRequest
13 голосов
/ 28 февраля 2009

Резюме

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

1012 * Pros *

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

Минусы

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

Примечания

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

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

Приложение 1

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

Ответы [ 8 ]

9 голосов
/ 28 февраля 2009

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

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

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

3 голосов
/ 02 марта 2009

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

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

3 голосов
/ 28 февраля 2009

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

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

О том, как вводить яйца, см. мой пост .

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

2 голосов
/ 04 марта 2009

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

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

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

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

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

2 голосов
/ 02 марта 2009

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

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

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

1 голос
/ 28 февраля 2009

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

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

1 голос
/ 28 февраля 2009

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

1 голос
/ 28 февраля 2009

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

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

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

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

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

...