Как установить egg python

Как установить egg python

What’s on this Page

.EGG вариант №

Файл EGG, также известный как яйца Python, представляет собой более старый формат дистрибутива Python. Это сжатый архив ZIP с расширением .egg, содержащий исходные файлы приложения Python вместе с метаинформацией о дистрибутиве. Файлы EGG являются альтернативой исполняемым файлам Windows EXE, но являются кроссплатформенными. Этот старый формат для дистрибутивов Python был заменен новым форматом файлов Wheel (WHL) в начале 2010 года.

Формат файла яйца

Файлы EGG сохраняются в виде сжатых ZIP-архивов. Это означает, что если вы замените расширение .egg на .zip, вы сможете открыть его с помощью стандартных утилит распаковки, таких как Corel WinZIP, Microsoft Explorer или RARLAB WinRAR.

Файлы EGG можно создавать с помощью пакета distutils, доступного в Python. Еще одним инструментом, который может создавать и открывать файлы EGG, является SetupTools. Файлы EGG можно установить как пакет с помощью easy_install.

«ПРИМЕЧАНИЕ. Формат файла EGG устарел в пользу нового формата файла колеса WHL».

Python-блог

Сегодня мы посмотрим противоречивый метод установки модулей и пакетов Python — easy_install. Мы так же узнаем как создавать собственные файлы *.egg. Для этого Вам понадобится пакет SetupTools . Этот пакет не поддерживает Python 3.x, так что если Вы работаете в третьей версии — смотрите в сторону pip или distribute . Про каждый из этих проектов я ещё напишу. Теперь давайте же начнём с SetupTools и easy_install.

SetupTools — это основной метод загрузки и установки пакетов Python с PyPI и других источников при помощи командной строки, что-то вроде apt-get для Python. Когда Вы установите SetupTools, заодно устанавливается скрипт или exe файл с названием easy_install, который Вы можете использовать для установки и обновления пакетов. Он так же позволяет Вам создавать eggs. Давайте потратим немного времени для знакомства с этой утилитой.

Использование easy_install для установки пакетов

После того, как Вы установили SetupTools, Вы можете использовать easy_install в вашей командной строке. Вот пример:

easy_install sqlalchemy

Этот скрипт обратится к PyPI и попробует загрузить последнюю версию SQLAlchemy оттуда, куда указывает PyPI пакет. Скрипт easy_install ещё и установит этот пакет. Но есть одна проблема, которая иногда встречается — easy_install может попробовать начать установку ещё до того, как завершится его загрузка, что может повредить установку. Но зато если Вы настроите ваш файл setup.py правильно, но заодно может скачать и установить все зависимости для этого пакета. Так что если Вы устанавливаете что-то сложное, типа TurboGears, он установит для Вас ещё кучу других пакетов. Это одна из причин, по которой Вы можете захотеть использовать virtualenv, в котором Вы сможете убедиться, что скачанные пакеты Вам нужны и работают как и надо. Если же окажется, что это не так — Вы сможете просто удалить папке virtualenv. Иначе Вам потребовалось бы лезть в папку Python и копаться в поисках новых пакетов и пытаться самому их удалить. Кроме того, easy_install после установки яиц добавляет яйца в файл easy_install.pth в папке site-packages, так что когда Вы их удаляете, Вам надо будет так же почистить этот файл. К счастью, Вы можете использовать pip для удаления этих яиц, если Вам не хочется делать это самому. Есть, конечно, команда -uninstall (-u), но я слышал разные отзывы про её работу.

Вы можете установить пакет так же передав напрямую easy_install url пакета. Другая прикольная фишка в том, что Вы можете сообщить easy_install версию пакета, которая Вам нужна, и он попробует установить именно её. Наконец, easy_install может провести установку из яйца или исходников. Для просмотра полного списка доступных команд смотрите документацию.

Создаём яйцо

Файлы egg — это формат распространения для пакетов Python. Это ещё одна альтернатива распространению пакетов при помощи исходников или двоичных файлов Windows, при этом важно понимать, что egg-файл является полностью кроссплатформенным. Мы посмотрим на то, как создаются яйца, используя пакет, который мы создали в предыдущем руководстве. Создадим новую папку и поместим в неё нашу папку mymath. Затем создадим файл setup.py в этой новой папке:

from setuptools import setup, find_packages setup( name = "mymath", version = "0.1", packages = find_packages() )

Обратите внимание, что вместо того, чтобы использовать функцию setup пакета distutils, мы используем setup пакета setuptools. Кроме того, мы используем функцию find_packages, которая автоматически находит все пакеты в текущей папке и добавляет их в яйцо. Для создания яйца Вам понадобится такая команда:

python setup.py bdist_egg

Вы получите в ответ много букаф, но в конце концов Вы увидите, что появилось три новых папки — build, dist и mymath.egg-info. Единственная папка, которая нас интересует — dist, в которой Вы найдёте наше яйцо — mymath-0.1-py2.6.egg. Обратите внимание, что на моём компьютере, поскольку я использую версию Python 2.6 — яйцо было создано именно для этой версии. Само яйцо по сути является zip файлом. Если Вы измените его расширение на zip, то сможете заглянуть внутрь и увидеть, что он содержит две папки — mymath и EGG-INFO. На данный момент у Вас должна быть возможность «натравить» easy_install на ваше яйцо и установить его.

Если Вы хотите, Вы можете так же использовать easy_install для выгрузки вашего яйца или исходников напрямую в Python Package Index (PyPI) используя следующие команды (скопировано из документации):

setup.py bdist_egg upload # создаём яйцо и выгружаем его
setup.py sdist upload # создаём дистрибутив исходников и выгружаем его
setup.py sdist bdist_egg upload # создаём и выгружаем и то и другое

Подведение итогов

На данный момент Вы должны уметь использовать easy_install или знать достаточно для того, чтобы попробовать одну из его альтернатив. Лично я сталкивался при работе с ним с разными проблемами и не планирую его использовать. В любом случае скоро мы посмотрим на pip и distribute, так что Вы сможете узнать, как их использовать. А пока — экспериментируйте с easy_install и делитесь своими впечатлениями в комментариях!

Домашнее чтение

• SetupTools документация
• EasyInstall документация
• The Hitchhiker’s Guide to Packaging
• Python разработка на Windows [Часть 2]: Установка easy_install…должна быть проще
• Как установить Python Easy_install для использования с Siri Server (youtube)
• Странный мир пакетов – форк setuptools от Tarek Ziade

Python на колёсах

Инфраструктура системы пакетов для Python долго подвергалась критике как от разработчиков, так и от системных администраторов. Долгое время даже само комьюнити не могло прийти к соглашению, какие именно инструменты использовать в каждом конкретном случае. Уже существуют distutils, setuptools, distribute, distutils2 в качестве базовых механизмов распространения и virtualenv, buildout, easy_install и pip в качестве высокоуровневых инструментов управления всем этим беспорядком.

До setuptools основным форматом распространения были исходные файлы или некоторые бинарные MSI-дистрибутивы для Windows. Под Linux были изначально сломанный bdist_dumb и bdist_rpm , который работал только на системах, основанных на Red Hat. Но даже bdist_rpm работал недостаточно хорошо для того, чтобы люди начали его использовать.

Несколько лет назад PJE попытался исправить эту проблему, предоставив смесь из setuptools и pkg_resources для улучшения distutils и добавления метаданных в Python-пакеты. В дополнение к этому он написал утилиту easy_install для их установки. По причине отсутствия формата распространения, поддерживающего метаданные, был предоставлен формат ‘яиц’ [egg].

Python eggs – обычные zip-архивы, содержащие python-пакет и необходимые метаданные. Хотя многие люди, вероятно, никогда намеренно не собирали egg’и, их формат метаданных до сих пор жив-здоров. И все разворачивают свои проекты с использованием setuptools.

К сожалению, некоторое время спустя сообщество разделилось, и часть его провозгласила смерть бинарных форматов и ‘яиц’ в частности. После этого pip, замена easy_install, перестал принимать egg-формат.

Потом прошло еще немного времени, и отказ от бинарных пакетов стал доставлять неудобства. Люди всё больше и больше стали деплоить на облачные сервера, а необходимость перекомпиляции C-шных библиотек на каждой машине не слишком радует. Так как ‘яйца’ на тот момент были малопонятны (я так полагаю), их переделали в новых PEP-ах, и назвали ‘колёсами’ [wheels].

В дальнейшем предполагается, что все действия происходят в virtualenv-окружении.

Что за колесо?

Начнём с простого. Что представляют собой ‘колёса’ и чем они отличаются от ‘яиц’? Оба формата являются zip-файлами. Главная разница в том, что egg можно импортировать без распаковки, wheel же придётся распаковать. Хотя нет никаких технических причин, делающих ‘колёса’ неимпортируемыми, поддержка их прямого импорта никогда даже не планировалась.

Другое различие в том, что ‘яйца’ содержат скомпилированные байткод, а ‘колёса’ – нет. Главное преимущество этого в том, что нет необходимости создавать отдельные wheel’ы для каждой версии Python до тех пор, пока не придётся распространять слинкованные через libpython модули. Хотя в новых версиях Python 3 при использовании стабильного ABI даже это уже можно провернуть.

Однако wheel-формат тоже не лишен проблем, некоторые из которых он наследует от ‘яиц’. Например, бинарные дистрибутивы под Linux до сих пор неприемлемы для большинства из-за двух недостатков: Python сам по себе компилируется под Linux в разных формах, и модули линкуются с разными системными библиотеками. Первая проблема вызвана сосуществованием несовместимых версий Python 2: USC2 и USC4. В зависимости от режима компиляции меняется ABI. В настоящее время wheel (насколько я могу судить) не содержит информации о том, с каким режимом Unicode связана библиотека. Отдельная проблема в том, что дистрибутивы Linux меньше совместимы между собой, чем хотелось бы, и обстоятельства могут сложиться так, что сборка, скомпилированная под один дистрибутив, не будет работать на остальных.

Всё это выливается в то, что, вообще говоря, на данный момент бинарные ‘колёса’ нельзя загружать на PyPI как несовместимые с различными системами.

В дополнение ко всему этому wheel сейчас знает только две крайности: бинарные пакеты и пакеты, содержащие чистый python-код. Бинарные пакеты специфичны для Python ветки 2.x. Сейчас это не кажется большой проблемой, потому что цикл 2.x подходит к концу, и пакетов, собранных только для 2.7, хватит надолго. Но если бы вдруг речь пошла про Python 2.8, была бы интересна возможность заявить, что этот пакет не зависит от версии Python, но он содержит бинарники, поэтому он не может не зависеть от архитектуры.

Единственный случай, оправдывающий существование такого пакета – это когда он содержит распределенные библиотеки, загружаемые с ctypes из CFFI. Такие библиотеки не связаны через libpython и не зависимы от реализации языка (их можно использовать даже с pypy).

Но есть и светлая сторона: ничто не запрещает использовать бинарные wheel’ы в своих собственных однородных инфраструктурах.

Сборка колеса

Итак, теперь мы знаем, что такое wheel. Как сделать своё собственное ‘колесо’? Сборка из собственных библиотек – простейший процесс. Всё, что нужно – свежая версия setuptools и библиотека wheel . Как только они оба установлены, ‘колесо’ собирается следующей командой:

$ python setup.py bdist_wheel 

Wheel будет создан в директории пакета. Однако есть одна вещь, которой следует опасаться: распространение бинарников. По умолчанию собираемое ‘колесо’ (при условии, что в setup.py не используется никаких бинарных шагов) состоит из pure-python кода. Это значит, что даже если распространять .so , .dylib или .dll как часть своего пакета, полученное ‘колесо’ будет выглядеть платформо-независимым.

Решение этой проблемы – вручную реализовать Distribution из setuptools, скинув флаг чистоты в false :

import os from setuptools import setup from setuptools.dist import Distribution class BinaryDistribution(Distribution): def is_pure(self): return False setup( . include_package_data=True, distclass=BinaryDistribution, ) 

Установка колеса

С использованием свежей версии pip ‘колесо’ ставится следующим образом:

$ pip install package-1.0-cp27-none-macosx_10_7_intel.whl 

Но что с зависимостями? Тут появляются некоторые сложности. Обычно одним из требований к пакету является возможность его установки даже без подключения к интернету. К счастью, pip позволяет отключать загрузку из индекса и устанавливать директорию, содержащую всё необходимое для установки. Если у нас есть wheel’ы для всех зависимостей необходимых версий, можно сделать следующее:

$ pip install --no-index --find-links=path/to/wheels package==1.0 

Таким образом будет установлена версия 1.0 пакета package в наше виртуальное окружение.

Колёса для зависимостей

Окей, но что, если у нас нет .whl для всех наших зависимостей? Pip в теории позволяет решить эту проблему использованием команды wheel . Это должно работать как-то так:

pip wheel --wheel-dir=path/to/wheels package==1.0 

Эта команда выгрузит все пакеты, от которых зависит наш пакет, в указанную папку. Но есть пара проблем.
Первая состоит в том, что в команде в настоящий момент есть баг, который не выгружает зависимости, которые уже являются ‘колёсами’. Так что если зависимость уже доступна на PyPI в wheel-формате, она не будет загружена.

Это временно решается shell-скриптом, который вручную перемещает из кэша скачанные wheel’ы.

#!/bin/sh WHEEL_DIR=path/to/wheels DOWNLOAD_CACHE_DIR=path/to/cache rm -rf $DOWNLOAD_CACHE_DIR mkdir -p $DOWNLOAD_CACHE_DIR pip wheel --use-wheel -w "$WHEEL_DIR" -f "$WHEEL_DIR" \ --download-cache "$DOWNLOAD_CACHE_DIR" package==1.0 for x in "$DOWNLOAD_CACHE_DIR/"*.whl; do mv "$x" "$WHEEL_DIR/$" done 

Вторая проблема чуть серьёзней: как pip найдет наш собственный пакет, если его нет на PyPI? Правильно, никак. Документация в таком случае рекомендует использовать не pip wheel package , а pip wheel -r requirements.txt , где requirements.txt содержит все необходимые зависимости.

Сборка пакетов c использованием DevPI

Такое временное решение проблемы зависимостей вполне применимо в простых ситуациях, но что делать, если есть множество внутренних python-пакетов, зависящих друг от друга? Такая конструкция быстро разваливается.

К счастью, в прошлом году Holker Krekel создал решение этой беды под названием DevPI, который по существу является хаком, эмулирующим работу pip с PyPI. После установки на компьютер DevPI работает как прозрачный прокси перед PyPI и позволяет pip-у устанавливать пакеты из локального репозитория. К тому же все пакеты, скачанные с PyPI, автоматически кэшируются, так что даже если отключить сеть, эти пакеты будут доступны для установки. И, в конце концов, появляется возможность загрузки своих собственных пакетов на локальный сервер, чтобы ссылаться на них так же, как и на хранящиеся в публичном индексе.

Я рекомендую установить DevPI в локальный virtualenv, после чего добавить ссылки на devpi-server и devpi в PATH .

$ virtualenv devpi-venv $ devpi-venv/bin/pip install --upgrade pip wheel setuptools devpi $ ln -s `pwd`/devpi-venv/bin/devpi ~/.local/bin $ ln -s `pwd`/devpi-venv/bin/devpi-server ~/.local/bin 

После этого остаётся просто запустить devpi-server , и он будет работать до ручной остановки.

$ devpi-server --start 

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

$ devpi use http://localhost:3141 $ devpi user -c $USER password= $ devpi login $USER --password= $ devpi index -c yourproject 

Так как я использую DevPI ‘для себя’, имена пользователя DevPI и системного пользователя совпадают. На последнем шаге создаётся индекс по имени проекта (при необходимости можно создать несколько).

Для перенаправления pip на локальный репозиторий можно сделать экспорт переменной окружения:

$ export PIP_INDEX_URL=http://localhost:3141/$USER/yourproject/+simple/ 

Я размешаю эту команду в скрипт postactivate моего virtualenv для предотвращения случайной загрузки из неверного индекса.

Для размещения собственных wheel’ов в локальном DevPI используется утилита devpi :

$ devpi use yourproject $ devpi upload --no-vcs --formats=bdist_wheel 

Флаг —no-vcs отключает магию, которая пытается определить систему контроля версий и перемещает некоторые файлы в первую очередь. Мне это не нужно, так как в моих проектах распространяются файлы, которые я не включаю в VCS (бинарники, например).

Напоследок я настоятельно рекомендую разбить файлы setup.py таким образом, что PyPI их отвергнет, а DevPI примет, чтобы случайно не зарелизить свой код с помощью setup.py resease . Самый простой способ это сделать – добавить неверный классификатор PyPI:

setup( . classifier=['Private :: Do Not Upload'], ) 

Заворачиваем

Теперь всё готово для начала использования внутренних зависимостей и сборки собственных ‘колёс’. Как только они появятся, их можно заархивировать, загрузить на другой сервер и установить в отдельный virtualenv.
Весь процесс станет чуть проще, когда pip wheel перестанет игнорировать существующие wheel-пакеты. А пока приведенный выше shell-скрипт – не худшее решение.

В сравнении с ‘яйцами’

Сейчас wheel-формат более притягателен, чем egg. Его разработка активнее, PyPI начал добавлять его поддержку и, так как с ним начинают работать утилиты, он похож на лучшее решение. ‘Яйца’ пока что поддерживаются только easy_install, хотя большинство давно перешло на pip.

Я считаю, что сообщество Zope до сих пор крупнейшее из базирующихся на egg-формате и buildout. И я считаю, что если решение на основе ‘яиц’ в вашем случае применимо, его и стоит применять. Я знаю, что многие не используют eggs вовсе, предпочитая создавать virtualenv-ы, архивировать их и рассылать по разным серверам. Как раз для такого развёртывания wheels – лучшее решение, так как у разных серверов могут быть разные пути к библиотекам. Встречалась проблема, связанная с тем, что .pyc -файлы создавались на билд-сервере для virtualenv, а эти файлы содержат конкретные пути к файлам. С использованием wheel .pyc создаются после установки в виртуальное окружение и автоматически будут иметь корректные пути.

Итак, теперь он у вас есть. Python на колёсах. И это вроде даже работает, и, возможно, стоит потраченного времени.

• Python
• Программирование

Python Egg: что это и для чего нужно?

Python Egg — это распространенный формат распределения Python-проектов. По сути, это всего лишь ZIP-архив, содержащий весь код проекта, а также некоторые дополнительные метаданные.

Представьте себе ситуацию, когда вы разрабатываете программу на Python, которая зависит от нескольких библиотек. Если бы не было системы управления пакетами, вам бы пришлось вручную загрузить и установить каждую из этих библиотек, что может быть довольно неудобно и затратно по времени. Кроме того, разные проекты могут зависеть от разных версий одной и той же библиотеки, что может вызвать конфликты.

Вот здесь на помощь приходят Python Eggs. Они представляют собой стандартный способ распределения Python-проектов, который позволяет упростить установку и управление зависимостями.

Python Egg включает в себя не только исходные файлы проекта, но и файл метаданных PKG-INFO, который содержит информацию о проекте, такую как его имя, версия, автор, лицензия и т.д., а также файлы .pyc, скомпилированные из исходного кода.

Чтобы создать Python Egg, вы можете использовать специальную утилиту setuptools. Вам просто нужно добавить некоторые метаданные в файл setup.py вашего проекта, а затем запустить команду python setup.py bdist_egg .

Таким образом, Python Eggs играют важную роль в упаковке и распространении Python-проектов. Они позволяют автоматизировать и упростить процесс установки и управления зависимостями, что, в конечном итоге, ускоряет разработку и облегчает поддержку проектов.