Чому бібліотеки постачаються окремо, а не в комплекті з кожною програмою?

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

Які аргументи я можу використати, щоб переконати їх?

Моя конкретна ситуація така: я працюю над SymPy , що є бібліотекою відкритого коду для символічної математики з відкритим кодом. Основною його частиною є mpmath , яка є бібліотекою для арифметики з плаваючою точкою з багатозапропонованими умовами . SymPy не працює без mpmath, альтернативи немає. Як такий, він постачався в комплекті з SymPy з самого початку (мені сказали, що зазвичай є невеликі несумісності для виправлення кожного разу, коли імпортується нова версія). Слід також зазначити, що розробник mpmath раніше брав участь у розробці SymPy. Зараз існує проблема щодо роз’єднання mpmath, про це можна прочитати тут .

Підсумовуючи обговорення там:

Роз’єднати:

• Дещо простіша перенесення на Python 3 (незначний аргумент IMHO)

• Простіша упаковка для дистрибуції

• Швидше (безпека) оновлення функцій для користувачів

• "Залежно від упаковки та обробки - це важкі проблеми, але вони вирішені. Це, безумовно, не сфера, де ми повинні робити свою справу".

Продовжуйте групувати:

• Установка. На Linux це легко, складніше на Mac і дуже складно в Windows. Відсутність доступу та інші проблеми.

• він є невід'ємною частиною SymPy, тобто. Симпі без нього не працює (зовсім)

• не існує іншого пакету, який би міг виконати роботу mpmath

• "Коли я, як користувач, завантажую sympy, я очікую, що він просто спрацює".

Це моя конкретна ситуація, але я б прийняв відповідь, яка також дає хорошу, загальну відповідь.

Ще одна відповідь, але одну, яку я вважаю найважливішою (лише моя особиста думка), хоча й інші - це хороші відповіді.

Упакування lib окремо дозволяє оновити lib без необхідності оновлення програми. Скажіть, що це помилка в лібі, замість того, щоб просто оновити її, вам доведеться оновити всю програму. Це означає, що вашій програмі знадобиться помилка версії, навіть якщо її код не змінився, саме через ліб.

Крім перелічених вами переваг (безпека, упаковка, особливості), я можу придумати ще кілька:

• Комусь, хто знайшов би функціонал корисним для іншої програми, не потрібно було б виконувати роботу з її поділу. Тобто вона навіть знає, чи функціональність у вашому проекті існує у першу чергу у вигляді бібліотеки. Це залежить від того, наскільки добре він розроблений ... якщо ваш проект достатньо модульний.

• У випадку, якщо це корисно для інших проектів, це в цілому зменшить розмір використання диска (наприклад, лише одна копія коду).

• Це покращило б якість вашого коду, змусивши вас зробити деякий (дуже потрібний) рефакторинг. Як і в першому пункті вище, це також залежить від якості вашого коду.

• Збільшення кількості користувачів бібліотеки (якщо вона відокремлена) допоможе зробити її більш загальною, що, ймовірно, також покращить її якість.

Хоча переваги очевидні, простота розгортання, здається, є головним аргументом для доставки бібліотеки разом із програмою у вашому випадку.

Ось ще кілька аргументів проти пакетування:

• У Linux це завдання диспетчера дистрибуції - гарантувати, що ваша бібліотека працює добре зі своїми залежностями. Більшість користувачів завантажують бібліотеку за допомогою диспетчера пакунків дистрибутива. Ті, хто використовує багажник, як правило, не проти витрачати час на налаштування бібліотеки.

• В Windows та Mac OS, менеджери пакетів Python, як-от pip, зазвичай використовуються, так як установка бібліотек вручну є громіздкою.

• Навіть існували аргументи щодо важкого розгортання в двигуні додатків Google, але не всі веб-рамки працюють на ньому. Багатьом потрібна навіть перенос, дисковий простір для бібліотек обмежений, і все-таки хостинг веб-додатків! Для веб-додатків навряд чи використовувати символічну математику.

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

• Люди часто ненавиджу це, коли програма вважає себе більш розумною, ніж вони. Нехай користувачі подбають про власну систему.

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

Один розмір не повинен відповідати всім.

Для розповсюдження джерел, якщо ви використовуєте пакет, що пакують пакунки для багатьох дистрибутивів (принаймні, спадщини Debian і Fedora), доведеться виконати додаткову роботу, щоб вимкнути або вилучити пакет, оскільки політика щодо пакетів для цих платформ забороняє або хоча б сильно перешкоджає комплектуванню. Таким чином, шляхом комплектування ви створюєте більше роботи для своєї нижчої течії з дуже невеликою користю. Чи може цей аргумент мати деяку вагу?

Бінарні дистрибутиви (якщо ви їх надаєте) можуть йти в будь-який бік; Пакетування, ймовірно, має сенс для тих, оскільки вони не використовуються вниз за течією.

Але немає причин, чому ви не можете прийняти протилежне рішення та пакет для інсталяторів Windows та Mac.

Зв'язування та залежність - це стара дискусія у світі упаковки. Цей документ розповідає про ці дві школи думки: http://www.aosabook.org/en/packaging.html