State of Python Packaging: Buildout, Distribute, Distutils, EasyInstall и т. Д.

Question

Последний раз, когда мне приходилось беспокоиться об установке пакетов Python, было два года назад, работая с Enthought, NumPy и . Этот опыт дал мне затяжные кошмары, связанные с причудливым поведением, устанавливающим & обновление пакетов Python в нестандартных точках (например, в $HOME/usr/local2.6/).

В любом случае, моя работа возвращает меня к установке различных пакетов Python. CheeseShop Tutorial упоминает DistUtils и EasyInstall в дополнение к Buildout! Мне трудно найти одно место, которое сравнивает эти (и другие) инструменты установки PyPi, поэтому я надеюсь подключиться к сообществу StackOverflow: Каковы сильные стороны & недостатки каждого инструмента установки?

Answer 1

Distribute - это новая вилка setuptools (easy_install), которая также должна быть рассмотрена. Даже Guido recommends it.

Строение ортогонально к упаковке --- вы можете use buildout with distribute.

Answer 2

Прежде всего, независимо от того, какой инструмент установки вы принимаете, начните использовать virtualenv --no-site-packages! Таким образом, пакеты python не устанавливаются глобально, и вы можете легко вернуться к тому, где были старые, а также новые проекты.

Теперь ваше сравнение представляет собой немного яблок и груш, поскольку перечисленные вами инструменты не являются взаимоисключающими. Тем не менее, я могу полностью рекомендовать Buildout. Он установит пакеты python, а также другие материалы и позволит вам автоматизировать установку и развертывание (сложных) проектов.

Кроме того, я рекомендую изучить Fabric как средство автоматизации административных задач.

Answer 3

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

Например, если вам нужно установить пакеты python на компьютерах Gentoo (GNU/Liunx), вы можете легко использовать g-pypi для создания ebuild для всех пакетов, которые используют distutils (а скорее: setup.py). Таким образом, они полностью интегрируются в вашу систему и могут быть добавлены, обновлены и удалены, как и все ваши другие инструменты. Но он, естественно, работает только для систем на основе Gentoo.

Также вы можете использовать yolk, чтобы узнать обо всех пакетах, установленных через easy_install в вашей системе (не только в Gentoo).

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

Answer 4

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

DistUtils и EasyInstall в дополнение к строительству!

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

Например, easy_install используется для установки пакетов distutils из pypi (cheeseshop) в каталог вашего сайта Python. Это значительно упрощает установку пакетов на ваш системный/глобальный sys.path.

easy_install очень удобен для пакетов, совместимых для всех проектов. Но я считаю, что предпочитаю использовать easy_install системы для установки пакетов, от которых не зависят проекты. Например, github-cli Я использую с каждым проектом, потому что он позволяет мне взаимодействовать с проблемами Github проекта из командной строки. Я использую это с проектами, но это для удобства, и сам проект не имеет зависимости от этого пакета.

Для управления зависимостями проекта я использую buildout. Buildout позволяет вам конкретно указать, из какой версии пакетов зависит ваш проект. Я предпочитаю buildout over pip-requirements.txt, потому что buildout является декларативным. С помощью pip вы устанавливаете пакеты, а в конце разработки вы создаете файл requirements.txt. С помощью Buildout, с другой стороны, вы изменяете buildout.cfg перед тем, как яйцо пакета добавляется в ваш проект. Это заставляет меня осознавать, какие пакеты я добавляю в проект.

Теперь есть вопрос virtualenv. Одна из наиболее популярных функций virtualenv - это, очевидно, --no-site-packages. Я не нашел этот вариант особенно полезным, потому что я использую buildout. Buildout управляет sys.path и включает только те пакеты, которые я прошу, чтобы он включал. Он также включает все в пакетные пакеты Python, но поскольку у меня нет ничего, что я использую в проектах, у меня никогда не было конфликтов.

Кроме того, я обнаружил, что -no-site-пакеты только мешают моему процессу разработки, потому что некоторые пакеты устанавливаются с использованием системы упаковки sistem. Как правило, все, что имеет библиотеки C, которые необходимо скомпилировать, я устанавливаю через систему упаковки системы.

В проекте fabfile.py Я включаю тестовую функцию для проверки наличия системных пакетов, которые устанавливаю через диспетчер пакетов системы.

В общем, вот как я использую эти инструменты:

диспетчера пакетов системы (APT-получить, ямс, порт, стукач ...) я использую один из них установить версии питона, которые я необходимости в этой системе. Я также использую его для установки пакетов, таких как lxml, которые включают библиотеки c.

easy_install Я использую для установки пакетов из PyPI, которые я использую на все проекты, но проекты не зависят от этих пакетов.

buildout Используется для управления зависимостями проекта.

По моему опыту этот рабочий процесс был очень гибким, портативным и легким в работе.

Answer 5

Всякий раз, когда мне нужно, чтобы напомнить себе о состоянии игры, я смотрю на них в качестве отправной точки:

• The State of Python Packaging, ответ:
• On packaging, связанные с:
• Tools of the Modern Python Hacker