Автостопом по Python

В некоторых проектах могут присутствовать и другие зависимости вроде базы данных Postgres, компилятора C или разделяемого объекта библиотеки C. Они могут быть не указаны явно, но при их отсутствии сборка прервется. Если вы строите библиотеки подобным образом, вам может помочь семинар Пола Керера (Paul Kehrer), посвященный распространению скомпилированных модулей (http://bit.ly/kehrer-seminar).

• Дистрибутив. Формат распространения пакета Python (и опционально других ресурсов и метаданных), имеющий форму, которая может быть установлена и затем запущена без дальнейшей компиляции (https://packaging.python.org/en/latest/wheel_egg/).

• Egg. Egg (это формат дистрибутива) представляют собой ZIP-файлы с особой структурой, содержащие метаданные для установки. Формат был введен благодаря библиотеке Setuptools и де-факто являлся стандартом многие годы, но никогда не был официальным форматом упаковки в Python. Был заменен на wheels на момент выхода PEP 427. Вы можете прочесть все о различиях между форматами в разделе Wheel vs Egg руководства по упаковке Python.

• Wheel. Это формат дистрибутива, который является стандартом для распространения библиотек Python. Они упаковываются как ZIP-файлы с метаданными, которые pip будет использовать для установки и удаления пакета. Файл имеет расширение. whl и следует соглашению по именованию (указываются платформа, сборка и использованный интерпретатор).

Помимо установленного Python, для запуска обычных пакетов, содержащих лишь код, написанный на Python, не нужно ничего, кроме других библиотек, написанных исключительно на Python, — их можно загрузить с PyPI (https://pypi.python.org/pypi) (или Warehouse (https://warehouse.pypa.io/) — грядущего нового местоположения для PyPI). Сложности (которые мы попытались обойти, добавив дополнительные шаги по установке в главе 2) возникают, когда библиотека Python имеет зависимости за пределами Python, например в библиотеках C или системных исполняемых файлах. Инструменты вроде Buildout и Conda придут на помощь, когда дистрибутив становится сложным даже для формата are Wheel.

Упаковываем код

Упаковка кода дистрибутива означает создание необходимой структуры файла, добавление требуемых файлов и определение подходящих переменных для comform, релевантных PEP, и текущих правил хорошего тона, описанных в разделе Packaging and Distributing Projects («Упаковка и распространение проектов») в Python Packaging Guide[76], или требования к упаковке для других репозиториев вроде http://anaconda.org/.

«Пакет» против «пакета дистрибутива» и против «пакета установки»

Может быть не очень понятно, почему слово «пакет» имеет так много значений. В данный момент мы говорим о пакетах дистрибутива, которые включают (обычные для Python) пакеты, модули и дополнительные файлы, необходимые для определения релиза. Мы также иногда называем библиотеки пакетами установки; они являются высокоуровневыми каталогами пакетов, которые содержат целую библиотеку. Наконец, простой пакет — это любой каталог, содержащий файл __init__.py и другие модули (файлы с расширением *.py). PyPA поддерживает глоссарий терминов, относящихся к упаковке (https://packaging.python.org/en/latest/glossary).

Conda

Если у вас установлен дистрибутив Python от Anaconda, вы все еще можете использовать pip и PyPI, но вашим менеджером пакетов по умолчанию будет conda, а репозиторием пакетов — http://anaconda.org/. При сборке пакетов мы рекомендуем следовать руководству, расположенному по адресу http://bit.ly/building-conda. Оно заканчивается инструкциями, как загружать пакеты на Anaconda.org.

Если вы создаете библиотеку для научных или статистических приложений — даже если сами не используете Anaconda, — вам понадобится установить дистрибутив для Anaconda, чтобы получить доступ к широкой аудитории научных работников, предпринимателей и пользователей Windows, которые пользуются Anaconda для получения бинарных файлов без лишних забот.

PyPI