Почему библиотеки поставляются отдельно, а не в комплекте с каждой программой?

10

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

Какие аргументы я могу использовать, чтобы убедить их?

Моя конкретная ситуация такова: я работаю над SymPy , библиотекой Python с открытым исходным кодом для символической математики. Основной его частью является mpmath , библиотека для многоцелевой арифметики с плавающей запятой. SymPy не работает без mpmath, альтернативы нет. Как таковой, он был связан с SymPy с самого начала (мне сказали, что обычно есть небольшие несовместимости, чтобы исправить каждый раз, когда импортируется новая версия). Также следует отметить, что разработчик mpmath раньше принимал участие в разработке SymPy. Теперь есть проблема с разделением mpmath, вы можете прочитать все это здесь .

Подведем итоги обсуждения:

Unbundle:

Несколько проще портировать на Python 3 (второстепенный аргумент ИМХО)
Более простая упаковка для раздачи
Быстрее (безопасность) обновления функций для пользователей
«Зависимости упаковки и обработки - это сложные проблемы, но они решаемы. Это определенно не та область, в которой мы должны заниматься своими делами».

Продолжайте связывать:

Монтаж. Это легко для Linux, сложнее для Mac и очень тяжело для Windows. Отсутствие доступа к су и другие проблемы.
это неотъемлемая часть SymPy, т.е. sympy не работает без него (вообще)
нет нет другого пакета, который может сделать работу mpmath
«Когда я, как пользователь, загружаю sympy, я ожидаю, что это просто сработает».

Это моя конкретная ситуация, но я бы принял ответ, который также дает хороший общий ответ.

package-management

— VPeric
источник

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

— чепанг

Является ли ваше приложение открытым исходным кодом?

— Антон Барковский

@Anton Да, это SymPy , библиотека Python с открытым исходным кодом для символической математики. Я работаю в нем как студент GSoC (полное раскрытие :)).

— VPeric

@Tshepang Обсуждение можно увидеть по адресу: code.google.com/p/sympy/issues/detail?id=2482

— VPeric,

@VPeric: Было бы очень приятно подвести итоги этой дискуссии, просто чтобы сэкономить время для тех, кто хочет ответить на ваш вопрос.

— чепанг

5

Еще один ответ, но тот, который я считаю наиболее важным (только мое личное мнение), хотя все остальные тоже хорошие ответы.

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

— Патрик
источник

1

Это важный момент, и это часть того, почему во многих дистрибутивах не нравится, когда библиотеки связаны с программами; Например, Debian придерживается политики не связывать библиотеку с исполняемым файлом или статически связывать библиотеку, если только она не может быть использована только этой конкретной программой (или, для статического связывания, в тех случаях, когда динамическое связывание не поддерживается).

— Жиль "ТАК - перестать быть злым"

В конце концов, это, пожалуй, самый важный момент. Я согласен и с другими ответами, но мне пришлось выбрать только один. :)

— VPeric

6

Помимо упомянутых вами преимуществ (безопасность, упаковка, функции), я могу подумать еще о нескольких:

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

— tshepang
источник

1

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

— VPeric

4

Хотя преимущества очевидны, простота развертывания кажется основным аргументом для доставки библиотеки вместе с программой в вашем случае.

Вот еще несколько аргументов против комплектации:

В Linux работа сопровождающего дистрибутива заключается в том, чтобы ваша библиотека работала хорошо с ее зависимостями. Большинство пользователей в любом случае загружают библиотеку, используя менеджер пакетов дистрибутива. Те, кто использует транк, обычно все равно будут тратить время на настройку библиотеки.
В Windows и Mac OS обычно все равно используются менеджеры пакетов Python, такие как pip, так как установка библиотек вручную затруднительна.
Были даже споры о жестком развертывании в движке приложений Google, но не все веб-фреймворки работают на нем. Многим даже требуется портирование, дисковое пространство для библиотек ограничено, и в конце концов это хостинг веб-приложений! Для веб-приложения маловероятно использование символической математики.
Никто не мешает вам отображать чистые сообщения об ошибках, если зависимость недоступна или имеет неправильную версию.
Люди часто ненавидят это, когда программа считает себя более умной, чем они. Пусть пользователи позаботятся о своей собственной системе.

— Антон Барковский
источник

Можете ли вы объяснить последний пункт. Я не могу сказать, если это аргумент за / против комплектации.

— Чепанг

3

Я понимаю, что в отличие от комплектации - пользователи хотят устанавливать то, что они хотят, а не заставлять меня навязывать им конкретную версию.

— VPeric

3

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

— Shadur
источник

3

Один размер не должен соответствовать всем.

Для исходных дистрибутивов, если вы связываете пакеты, упаковщики во многих дистрибутивах (по крайней мере, из наследий Debian и Fedora) должны будут выполнить дополнительную работу, чтобы отключить или удалить пакетирование, так как политики пакетов для этих платформ запрещают или, по крайней мере, строго препятствуют пакетированию. Поэтому, объединяя, вы создаете больше работы для вашего нижестоящего процесса с очень небольшой выгодой. Может ли этот аргумент иметь вес?

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

Но нет причины, по которой вы не можете принять иное решение и пакет для установщиков Windows и Mac.

— Майкл Экстранд
источник

1

Хотя я согласен в целом, это создает дополнительное бремя (пусть и небольшое), которое означает, что, вероятно, никто не поддержит это решение.

— VPeric

2

Связывание и зависимость - давняя дискуссия в мире упаковки. Этот документ рассказывает об этих двух школах мысли: http://www.aosabook.org/en/packaging.html

— Эрик Араужо
источник

2

Это было интересное чтение, но в нем больше говорится о деталях реализации и различных особенностях Python, чем об общей философии.

— VPeric