Рекомендации по развертыванию Python - несколько версий, стандартные места установки, инструменты для упаковки и т.д.

Многие сообщения по разным аспектам этого вопроса, но я не видел сообщения, которое объединяет все это.

Сначала субъективное утверждение: кажется, что простота, которую мы испытываем при работе с языком Python, раскалывается, когда мы выходим за пределы интерпретатора и начинаем бороться с проблемами развертывания. Как лучше всего иметь несколько версий Python на одной машине? Где должны быть установлены пакеты? Disutils vs. setuptools vs. pip и т.д. Кажется, что Zen Python сильно злоупотребляет, когда дело доходит до развертывания. Я чувствую жуткие отголоски опыта "DLL ад" в Windows.

Вы запускаете несколько версий Python на одном компьютере? Как вы уверены, что они могут сосуществовать, а более новая версия не нарушает предположений о других процессах, которые полагаются на более раннюю версию (например, сценарии, предоставляемые поставщиком ОС)? Это безопасно? Достаточно ли virtualenv?

Каков наилучший выбор мест для разных компонентов среды Python (включая сторонние пакеты) в локальной файловой системе? Существует ли строгое или грубое соответствие между местоположениями для разных версий Unixy и ОС Windows, на которые можно положиться?

И самый мутный угол болота - какие инструменты для установки вы используете (setuptools, distutils, pip и т.д.), и они хорошо сочетаются с вашими выборами: расположение файлов, виртуальные среды Python, путь Python и т.д.

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

Ответы

Ответ 1

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

О вашем субъективном заявлении: я не понимаю, почему простота и элегантность Python означают, что вопросы упаковки и развертывания внезапно станут простыми вещами. Некоторые вещи, связанные с упаковкой, просты, другие - нет, другие могут быть. Было бы лучше для пользователей, если бы у нас была одна полная, надежная и простая система упаковки, но это не так. distutils был создан, а затем его развитие приостановлено, setuptools был создан и добавлен новые решения и новые проблемы, распространение было раздвоено из setuptools из-за социальных проблем, и, наконец, distutils2 был создан, чтобы сделать одну официальную полную библиотеку. (Подробнее о Различия между дистрибутивами, distutils, setuptools и distutils2?) Ситуация далека от идеала для разработчиков и пользователей, но мы работаем над тем, чтобы сделать ее лучше.

Как лучше всего иметь несколько версий Python на одной машине? Используйте менеджер пакетов, если вы используете современную ОС, или используйте "make altinstall", если вы компилируете исходный код в UNIX, или используйте аналогичную неконфликтную схему установки, если вы компилируете исходный код в Windows. Как пользователь Debian, я знаю, что я могу вызывать отдельные версии, используя "pythonX.Y", и что версии по умолчанию ( "python" и "python3" ) решаются разработчиками Debian. Некоторые ОС начали нарушать предположение о том, что python == python2, поэтому в настоящее время существует PEP, чтобы благословить или осудить это: http://www.python.org/dev/peps/pep-0394/ Windows, похоже, не имеет возможности использовать одну версию Python по умолчанию, поэтому theres другой PEP: http://www.python.org/dev/peps/pep-0397/

Где должны быть установлены пакеты? Используя distutils, я могу устанавливать проекты в каталог моего сайта user-packages (см. PEP 370 или docs.python.org). В чем вопрос?

Параллельная установка разных версий одного и того же проекта не поддерживается. Для обсуждения изменений в системе импорта и инструментах упаковки потребуется PEP. Прежде чем кто-то начнет обсуждение, использование virtualenv или buildout будет достаточно хорошо.

Я не понимаю вопроса о расположении "компонентов среды Python".

В основном я использую системные пакеты (т.е. используя диспетчер пакетов Aptitude на Debian). Чтобы опробовать проекты, я клонирую их репозиторий. Если мне нужно что-то, недоступное с Aptitude, я устанавливаю (или помещаю .pth файл в репо) в каталоге моего сайта user-packages. Мне не нужен пользовательский PYTHONPATH, но я изменил местоположение своих пакетов-сайтов с помощью PYTHONUSERBASE. Мне не нравится концепция магии и яиц в setuptools/distribute, поэтому я их не использую. Ive начал использовать virtualenv и pip для одного проекта (они используют setuptools под обложкой, но я сделал частную установку, поэтому мой глобальный Python не имеет setuptools).

Ответ 2

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

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

Ответ 3

Одним из ресурсов для этой области является книга Expert Python Programming от Tarek Ziade. Я неоднозначно отношусь к качеству книги, но затронутые темы - это то, на что вы фокусируетесь.