Пакеты Python часто размещаются во многих репозиториях дистрибутива. После прочтения этого руководства, в частности, раздела под названием «Вы действительно хотите это сделать», я избегал использования pip и предпочел использовать системный репозиторий, прибегая к pip только тогда, когда мне нужно установить пакет, отсутствующий в репозитории.

Однако, поскольку это несовместимый метод установки, лучше ли будет использовать только pip? Каковы преимущества / недостатки в использовании pip по сравнению с собственным репозиторием системы для пакетов, которые доступны в обоих местах?

Ссылка, которую я включил, сообщает

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

Я использую арку. Это относится и к другим системам управления пакетами, кроме apt?

Самый большой недостаток, который я вижу при использовании pipдля установки модулей Python в вашей системе, как системных модулей, так и пользовательских модулей, заключается в том, что система управления пакетами вашего дистрибутива не будет знать о них. Это означает, что они не будут использоваться для любого другого пакета, который нуждается в них, и который вы, возможно, захотите установить в будущем (или который может начать использовать один из этих модулей после обновления); Затем вы получите обе pip- и управляемые дистрибутивом версии модулей, которые могут вызвать проблемы (я недавно столкнулся с еще одним примером этого ). Таким образом, ваш вопрос в конечном итоге является предложением «все или ничего»: если вы используете толькоpip для модулей Python вы больше не можете использовать менеджер пакетов вашего дистрибутива для всего, что хочет использовать модуль Python ...

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

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

TL; DR

• использовать pip(+ virtualenv) для вещей (libs, frameworks, возможно, dev tools) ваших проектов (которые вы разрабатываете)
• использовать менеджер пакетов для приложений, которые вы используете (как конечный пользователь)

Зависимости развития

Если вы разрабатываете программное обеспечение на Python, вы захотите использовать его pipдля всех зависимостей проекта, будь то зависимости времени выполнения, зависимости времени сборки или что-то, что необходимо для автоматизированного тестирования и автоматических проверок соответствия (линтер, средство проверки стиля, средство проверки статического типа). ...)

На это есть несколько причин:

• Это позволяет вам использовать virtualenv (либо напрямую, либо через virtualenvwrapper, либо pipenv, либо другими способами), чтобы отделить зависимости различных проектов друг от друга и изолировать приложения на python, которые вы используете «в работе» (как пользователь), от любых экзотических махинаций (или даже просто несовместимости), которые могут продолжаться в развитии.
• Это позволяет вам отслеживать все зависимости проекта в requirements.txt(если ваш проект является приложением) или setup.py(если ваш проект является библиотекой или структурой) файл. Это можно проверить в системе контроля версий (например, Git) вместе с исходным кодом, чтобы вы всегда знали, какая версия вашего кода зависит от того, какие версии ваших зависимостей.
• Вышеуказанное позволяет другим разработчикам совместно работать над вашим проектом, даже если они не используют один и тот же дистрибутив Linux или даже не одну и ту же операционную систему (если используемые зависимости также доступны на Mac и Windows или независимо от того, что они используют).
• Вы не хотите, чтобы автоматические обновления диспетчера пакетов вашей операционной системы нарушали ваш код. Вам следует обновить свои зависимости, но вы должны делать это осознанно, а иногда и по своему усмотрению, чтобы вы могли быть готовы исправить свой код или откатить обновление. (Что легко, если вы отслеживаете полное объявление зависимостей в вашей системе контроля версий вместе с вашим кодом.)

Если вы чувствуете, что вам необходимо разделить прямые и косвенные зависимости (или отличить приемлемый диапазон версий для зависимости от фактической версии, см. «Закрепление версии»), изучите pip-tools и / или pipenv. Это также позволит вам различать зависимости между сборкой и тестированием. (Различие между зависимостями сборки и времени выполнения может быть закодировано в setup.py)

Приложения, которые вы используете

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

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

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

В моем личном ящике разработчика я использую 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 и не могут его получить, состоит в том, чтобы использовать систему User, как описано ниже.

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

Тем не менее, возможно, существуют обстоятельства, когда совершенно разумно сделать доступной больше среды разработки. У вас могут быть интерфейсы Python в сложные пакеты (например, СУБД), где вы хотите использовать системную версию этого, и вы чувствуете, что лучше всего также позволить системе выбирать конкретный код библиотеки Python, который вы будете использовать для общения с ним. Или вы можете развернуть множество хостов с базовой средой разработки для класса Python, и вам будет проще автоматизировать их с помощью стандартных системных пакетов.

Пользовательские ежедневные программы и пакеты

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

Обычно pip --userэто то, что люди будут использовать для этого, хотя некоторые зависимости, такие как сам интерпретатор Python, требуют немного большего. pyenv и pythonz полезны для создания личных интерпретаторов (независимо от того, установлены ли они в ~/.local/binкачестве интерпретатора по умолчанию или иным образом), и, конечно, всегда можно просто собрать «вручную» из исходного кода, если библиотеки dev доступны.

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

Отдельные среды разработки приложений и среды выполнения

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

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