Пакети Python часто розміщуються у багатьох сховищах дистрибутива. Прочитавши цей підручник, зокрема розділ під назвою "Ти справді хочеш це зробити", я уникав використання pip і вважав за краще використовувати системне сховище, вдаючись до pip, коли мені потрібно встановити пакет не в сховищі.

Однак, оскільки це непослідовний спосіб встановлення, чи краще було б використовувати лише pip? Які переваги / недоброзичливці використовувати pip через власне сховище системи для пакетів, які доступні в обох місцях?

Посилання я включав держави

Перевага завжди використовувати стандартні пакети Debian / NeuroDebian, полягає в тому, що вони ретельно перевіряються на сумісність один з одним. Пакети Debian записують залежності в інші бібліотеки, тому ви завжди отримаєте потрібні бібліотеки в рамках встановлення.

Я використовую арку. Це так з іншими системами управління пакетами, крім apt?

Найбільшим недоліком, який я бачу при використанні pipдля установки модулів Python у вашій системі, як системних модулів, так і як модулів користувачів, є те, що система управління пакунками вашого дистрибутива не буде знати про них. Це означає, що вони не будуть використовуватися для будь-якого іншого пакета, який їм потрібен, і який ви, можливо, захочете встановити в майбутньому (або який може почати використовувати один з цих модулів після оновлення); тоді ви отримаєте як pipмодулі, так і керовані дистрибуцією версії модулів, що може спричинити проблеми (я нещодавно зіткнувся з ще одним екземпляром цього ). Таким чином, ваше запитання, в свою чергу, є пропозицією, яка повністю або нічого: якщо ви використовуєте лише виpip що стосується модулів Python, ви більше не можете використовувати диспетчер пакунків дистрибутива ні для чого, що хоче використовувати модуль Python ...

Загальна порада, надана на сторінці, на яку ви пов’язані, дуже хороша: намагайтеся максимально використовувати пакети вашого дистрибутиву, використовуйте лише pipдля модулів, які не упаковані, і коли ви це зробите, зробіть це в налаштуваннях користувача, а не в системі, широкий. Використовуйте віртуальні середовища, наскільки це можливо, зокрема для розробки модулів. Особливо в Arch, ви не повинні стикатися з проблемами, викликаними старими модулями; навіть у дистрибутивах, де це може бути проблемою, віртуальні середовища вирішують це досить легко.

Завжди варто враховувати, що бібліотека та пакети модулів дистрибутива пакуються в основному для використання інших пакетів у дистрибутиві; наявність їх навколо - хороший побічний ефект для розвитку з використанням цих бібліотек і модулів, але це не є основним випадком використання.

TL; DR

• використовувати pip(+ virtualenv) для матеріалів (libs, frameworks, можливо інструменти для розробників) ваші проекти (які ви розробляєте) використовуйте
• використовувати менеджер пакунків для програм, які ви використовуєте (як кінцевий користувач)

Залежності від розвитку

Якщо ви розробляєте програмне забезпечення в Python, ви хочете використовувати його pipдля всіх залежностей проекту, будь то залежність від часу виконання, залежність від часу побудови чи інше, необхідне для автоматизованого тестування та автоматизованих перевірок відповідності (лінійка, перевірка стилів, перевірка статичного типу) ...)

Для цього є кілька причин:

• Це дозволяє використовувати virtualenv (безпосередньо чи через virtualenvwrapper або pipenv чи іншими способами), щоб відокремити залежності різних проектів один від одного та ізолювати додатки python, які ви використовуєте "у виробництві" (як користувач) від будь-яких екзотичних шенагів (або навіть просто несумісності), які можуть продовжуватись у розвитку.
• Це дозволяє відстежувати всі залежності проекту у файлі requirements.txt(якщо ваш проект є додатком) або setup.py(якщо ваш проект - бібліотека чи фреймворк). Це можна перевірити в контролі редагування (наприклад, Git) разом із вихідним кодом, щоб ви завжди знали, яка версія коду покладається на які версії ваших залежностей.
• Вищезазначене дозволяє іншим розробникам співпрацювати над вашим проектом, навіть якщо вони не використовують один і той же дистрибутив Linux або навіть не ту ж операційну систему (якщо використовувані залежності також доступні на Mac і Windows або що б там не сталося, тобто)
• Ви не хочете, щоб автоматичні оновлення менеджера пакунків вашої операційної системи порушували ваш код. Вам слід оновити свої залежності, але ви повинні робити це свідомо та часом, щоб вибрати, щоб ви могли бути готовими виправити код або скасувати оновлення. (Що легко, якщо ви відстежуєте повну декларацію залежності у вашій системі контролю версій разом із кодом.)

Якщо вам здається, що вам потрібно розділити прямі та непрямі залежності (або розрізняти прийнятний діапазон версій для залежності та фактичну використану версію, пор. "Прикріплення версії"), загляньте в pip-інструменти та / або pipenv. Це також дозволить вам розрізняти залежності побудови та тестування. (Можливо, різниця між залежностями побудови та часу виконання може бути закодована setup.py)

Програми, які ви використовуєте

Для речей, які ви використовуєте як звичайний додаток і які просто трапляються записаними в Python, віддайте перевагу менеджеру пакетів вашої операційної системи. Це переконається, що він залишається досить сучасним та сумісним з іншими речами, встановленими менеджером пакунків. Більшість дистрибутивів Linux також запевняють, що вони не поширюють жодної шкідливої ​​програми.

Якщо те, що вам потрібно, не доступне в репо-пакеті за замовчуванням вашого дистрибутива, ви можете переглянути додаткові репозитивні пакети (наприклад, стартові панелі дистрибутивів на основі деб) або скористатися pipбудь-яким чином. Якщо останнє, використовуйте --userдля встановлення в будинок свого користувача замість загальносистемного, щоб менше шансів зламати вашу установку Python. (Для речей, які вам потрібні лише тимчасово або рідко, ви навіть можете використовувати virtualenv.)

Ще одна причина, що стосується менеджера пакунків, полягає в тому, що оновлення будуть автоматично застосовані, що є критичним для безпеки. Подумайте, якби пакет бобів Equifax був автоматично оновлений за допомогою yum-cron-безпеки, злому, можливо, не відбулося.

У особистому вікні розробника я використовую Pip, в prod я використовую пакети.

Якщо ми говоримо про встановлення пакетів python для використання в написаному вами коді, використовуйте pip.

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

Якщо ви плануєте випустити будь-який код python, як правило, ви додасте setup.pyабо requirements.txtдо свого проекту, що дозволить pip автоматично отримувати всі його залежності. Дозволяє вам легко створити або відтворити віртуальне середовище для цього проекту.

Підсумок

Є три загальні категорії модулів, з якими ви маєте справу:

1. Ті підтримуючі програми, встановлені для всіх користувачів із системою пакетів ОС. (Це може включати навіть інструменти та бібліотеки, які використовуються людьми, які програмують в Python; див. Нижче.) Для цього ви використовуєте пакети ОС, де можна, і pipвстановлюєте в системні каталоги, де це необхідно.
2. Ті програми підтримки, встановлені певним користувачем, лише для її власного використання, а також для певних аспектів її "щоденного" використання Python як мови сценаріїв. Для цього вона використовує pip --user, можливо, pyenv або pythonz , і подібні інструменти та тактику.
3. Ті, хто підтримує розробку та використання конкретного додатку. Для цього ви використовуєте virtualenv(або подібний інструмент).

Кожен рівень тут також може отримувати підтримку з попереднього рівня. Наприклад, наш користувач в (2) може покладатися на інтерпретатор Python, встановлений через пакети ОС.

Розглянемо це трохи детальніше:

Системні програми та пакети

Програми, написані на Python, які ви хочете "просто запустити", прості: просто скористайтеся інструментами для встановлення ОС та дозвольте їм вносити все, що їм потрібно; це нічим не відрізняється від не-Python програми. Це, ймовірно, призведе до інструментів / бібліотек Python (наприклад, самого інтерпретатора Python!), На які користувачі вашого апарату можуть почати покладатися; це не проблема, якщо вони розуміють залежність і в ідеалі знають альтернативні способи впоратися з нею на хостах, які не забезпечують цих залежностей.

Поширений і простий приклад такої залежності - це деякі мої особисті сценарії, ~/.local/bin/які починаються з цього #!/usr/bin/env python. Вони працюватимуть добре (доки вони працюють під Python 2) на RH / CentOS 7 та більшості (але не всіх) установок Ubuntu; вони не будуть здійснюватися під базовою установкою Debian або в Windows. Наскільки мені не подобається моє особисте середовище, що значно перешкоджає залежності від пакетів ОС (я працюю над багатьма різними ОС), щось подібне я вважаю досить прийнятним; мій план резервного копіювання для рідкісних хостів, у яких немає системного Python і не може отримати його, - це користуватися системою користувача, як описано нижче.

Люди, які використовують системний інтерпретатор пітона, зазвичай також залежать від системи pip3. Ось де я зазвичай малюю лінію на моїх системних залежностях; все virtualenvвперед я маю справу з собою. (Наприклад, мій стандартний сценарій активації покладається на те , що знаходиться на шляху pip3чи pipє, але завантажує власну копію програми virtualenvдля завантаження віртуального середовища, яке вона створює.

Однак, мабуть, є обставини, коли цілком розумно зробити більше доступним для середовища розвитку. У вас можуть бути інтерфейси Python у складних пакетах (таких як СУБД), де ви хочете використовувати системну версію цієї версії, і вам здається, що найкраще також дозволити системі вибрати конкретний код бібліотеки Python, який ви будете використовувати для розмови з нею. Або ви, можливо, розгортаєте безліч хостів з базовим середовищем розробки для класу Python, і вам найпростіше автоматизувати стандартні системні пакети.

Програми та пакети "Щоденні" користувача

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

Як правило pip --user, те, що люди будуть використовувати для цього, хоча певні залежності, такі як інтерпретатор Python, вимагають трохи більше, ніж це. pyenv та pythonz корисні для створення особистих перекладачів (будь то встановлений ~/.local/binдля перекладача за замовчуванням чи іншим способом), і, звичайно, завжди можна створити "вручну" з джерела, якщо бібліотеки розробників доступні.

Я намагаюся зберегти мінімальний набір встановлених тут речей: virtualenvwrapper (оскільки я ним постійно користуюся) і, можливо, остання версія pip. Я намагаюся уникати залежностей поза стандартною бібліотекою або на Python 3 для особистих сценаріїв, які я пишу, щоб використовуватись у багатьох хостах. (Хоча ми побачимо, як довго я можу протриматися з цим, коли я переміщу все більше і більше цих особистих сценаріїв до Python.)

Окреме середовище розробки додатків та середовища виконання

Це звичайна віртуолв річ. Для розробки вам майже завжди слід використовувати virtualenv, щоб переконатися, що ви не використовуєте системні залежності, або часто більше одного для тестування на різні версії Python.

Ці віртуальні середовища також хороші для додатків з великою кількістю залежностей, де ви хочете уникнути забруднення вашого користувальницького середовища. Наприклад, я зазвичай встановлюю virtualenv для запуску ноутбуків Юпітера тощо.