Я когда с python eggs только начинал (где-то года полтора назад), мне они казались жутко неудобной и “кривой” вещью. Зачем еще какой-то менджер py-пакетов если уже есть apt?

Но поразбравшись с ними, я понял, что нужно его правильно готовить . Более того, в egg есть встроенный механизм плагинов , что очень здорово. Однако bialix утверждает, что с ним есть проблемы .

Я для себя давно решил :) Поэтому pytils не будут никогда не иметь внешних зависимостей (однако понимают easy_install), а ydbf будут зависеть и активно использовать setuptools.

Высказывайтесь, что у вас накопилось по поводу яиц :) Мнения, впечатления, опыт, факты, вопросы…

: http://gorod-omsk.ru/blog/pythy/2006/12/21/cooking-python-eggs/ или http://python-breeder.livejournal.com/12796.html
: http://gorod-omsk.ru/blog/pythy/2007/02/18/understanding-eggs-entrypoints/ или http://python-breeder.livejournal.com/14642.html
: http://python.com.ua/forum/viewtopic.php?pid=3479#p3479
: http://gorod-omsk.ru/blog/pythy/projects/pytils/ или http://cheeseshop.python.org/pypi/pytils
: http://gorod-omsk.ru/blog/pythy/projects/ydbf/ или http://omsk.lug.ru/wacko/Python/Dbf/YDbf

я покачто на той стадии, когда беру egg и тупо распаковываю в папку с модулями питона В))
не сильно люблю это дело, python setup.py install попривычней, хотя надо будет разобраться с темой

К eggs отношусь нормально, но часто я нуждаюсь в просмотре исходников библиотек, в ковырянии, в расставлении print'ов с дебаггами.
А с eggs это не очень удобно. Хотя в плане установки все очень даже бодренько )

Складывается ощущение, что egg не любят как раз админы за несовместимость с привычными пакетными менеджерами. Если забыть об этом, то штука очень даже удобная и нужная.

Тут некоторые всё грозились написать дружилку egg с RPM (deb). Если получиться, основная проблема уйдёт в небытье.

Pythy: огромное Спасибо за статью о egg'ах. По настоящему просвещающая, без воды.

Я не стану утверждать, что они – сущее зло, но замечу, что их влияние пока еще не до конца изучено.

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

Во-вторых, мне кажется дискуссии насчет eggs vs rpm – это очень линукс-центрированная точка зрения. Почем-то народ рассматривает яйца именно как аналог менеджера установки. Это далеко не вся правда, а только видимая часть айсберга.

Собственно – это явная бородавка в питоне или дырка в дизайне пакета distutils: в наборе команд установки отсутствует одна очень простая вещь: команда uninstall. И это приводит к очень неприятным последствиям. Только подумайте об этом минутку. Т.е. при создании команды install предполагалось, что дополнительные библиотеки устанавливаются раз и навсегда. Может быть 10 лет назад, когда релизы выпускались не столь часто, как это модно делать сейчас по agile-технологии, это имело смысл, но сейчас – это просто вопиющая дырка.

К счастью для пользователей windows если устанавливать либы при помощи инсталлятора, который можно собрать даже на linux(!) при помощи команды setup.py bdist_wininst, так вот если устанавливать либы при помощи такого инсталлятора, то возможность деинсталляции появляется, через привычный диалог “Установка и удаление программ”. И в принципе, если скрипт setup.py написан без заморочек, то я обычно сам делаю инсталлятор вместо вызова setup.py install, и уже потом устанавливаю инсталлятором. Потому что удалять установленные либы руками – удовольствие для мазохистов.

Яйца (насколько я мог судить из анонсов) наконец-то исправили проблему с отсутсвием uninstall. Кроме этого они как бы реализовали систему разрешения внешних зависимостей (на этапе установки и выполнения). Именно этого не хватало питону. Разрешение зависимостей кстати отсутствует и в случае bdist_wininst.

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

Теперь о менее очевидных вещах. Пока что я не видел реальных замеров скорости работы с яйцами и без. Однако, здравый смысл подсказывает, что раз яйца привносят множество магии в обычный рантайм питона (подстановку путей в sys.path, работу с точками входа а-ля плагины), то это самым прямым образом скажется на времени старта *всех* питон-приложений, даже тех, которые яйца не используют. А для тех, которые работают непосредственно из яиц, эта цифра будет даже хуже. Все мы знаем, что питон не самая быстрая среда исполнения. Но отдают ли себе яйцепоколонники отчет в том, что яйца мешают танцору еще сильнее чем кривые ноги? Я вполне серьезно.
Если ваше приложение стартует один раз при инсталляции на сервере, и потом крутится там месяцами-годами, то это один момент и вы на это с чистой совестью можете наплювать. Если же у вас утилита командной строки, которая “по идее” должна вызываться часто и работать шустренько? В одном месте я читал, что оверхед при старте за счет яиц может составлять до 50-100мс. Я пытаюсь представить насколько все будет плохо когда site-packages будет завалена кучей яиц. Лично у меня для комфортной работы установлено порядка 15-20 дополнительных библиотек. И только недавно я столкнулся с яйцами.

Так что мне кажется – не все так гладко с этими яйцами, хоть они и овальные на вид. Просто яйцемания пока еще в начале своего пути и вероятно на некоторые грабли еще просто не успели наступить. Я на одну маленькую наступил. Хотя эту проблему я могу обойти немного изменив свое приложение, чтобы наличие/отсутствие setuptools на него не влияло. Но осадок остался.

Мне кажется тут еще проблема в том, что setuptools дает в руки питонистов инструмент, при помощи которого они могут больше лениться и меньше продумывать вопросы установки. Например, я столкнудся с необходимостью иметь setuptools только для того, чтобы установить либу Pygments. Хотя эта либа использует только одну-единственную функцию из setuptools: автоматическое нахождение питон-пакетов в рабочем дереве для установки. Фсе. Никаких яичных плагинов, ни даже установка в виде zip-архива ничего для рантайма не используется. Я считаю, что вот такие случаи – это маразмы.

Да и еще один минус яиц – полная ориентация на постоянное подключение к инету во время установки. Я понимаю, что во всех цивилизованных странах широкополосный интернет – норма жизни. Но вещи выглядят гораздо хуже, когда ты живешь в каком-нибудь Мухосранске. Хотя даже некоторые западные товарищи отмечали в своих блогах эту фичу setuptools как неудобство.

Во, правильные слова. Да, стоит понимать, что eggs несет в себе как преимущества, так и недостатки. И уж всяко это не “серебрянная пуля”. Откровенно говоря, setuptools весьма-весьма сыры, однако разумной альтернативы нет.

bialix
Отказ от пакетов типа rpm и переход на яйца – это огромный плюс для линуксоидов, поскольку хоть у вас господа хорошие и есть репозитории rpm, но их актуальность и своевременность обновления лежит на кураторах конкретных пакетов в каждом конкретном дистрибутиве. Т.е. по сути каждый дистрибутив линукса должен иметь своих кураторов, которые будут следить за своевременным добавлением новых версий питон-либ. Очевидно, что это дублирование усилий многих людей. При использовании яиц же получается эту работу делает только один раз автор каждой либы. Т.е. выигрыш налицо?

К сожалению не все так просто. Поставленный через eggs модуль не будет добавлен в базу рпм и отсюда получаем ряд неудоств:
1) Невозможность определения принадлежности файла пакету.
2) При установке проги в зависимостях которой есть модуль установленный через eggs, мы получаем поломанную зависимость.
3) При обновлении системы н-р через apt или yum есть возможность вытянуть более старую версию этого модуля и при попытки установки получить конфликт файлов.
Так же увеличиваем количество систем управления пакетами(напоминает слаку с рпм :) ).
Пока единственный реальный выход, который я вижу - это в случае отсутствия нужного модуля в репозитории дистриба, собрать для его установки рпм самостоятельно.

P.S. Кураторов пакетов обычно называют майнтейнерами(maintainer) :)

slivlen
P.S. Кураторов пакетов обычно называют майнтейнерами(maintainer) :)

Да я знаю. Но в русском переводе книги Эрика Реймонда “Искусство программирования UNIX” maintainers переведены именно как кураторы. И *лично* *мне* это слово больше нравится чем английская калька.

bialix
Отказ от пакетов типа rpm и переход на яйца – это огромный плюс для линуксоидов, поскольку хоть у вас господа хорошие и есть репозитории rpm, но их актуальность и своевременность обновления лежит на кураторах конкретных пакетов в каждом конкретном дистрибутиве.

Это не так в силу трёх причин:
1. Мейнтейнеры проверяют сопряжение компонент и вписываемость конкретной программы в дистрибьютив.
2. RPM (deb) контролирует все файлы, в то время как egg управляет только python.
3. Собрать rpm для чего-то на python'е не так сложно как кажется, а выгода огромна. К тому же, ничего не мешает самому стать “куратором” :)

Maximbo

bialix
Отказ от пакетов типа rpm и переход на яйца – это огромный плюс для линуксоидов, поскольку хоть у вас господа хорошие и есть репозитории rpm, но их актуальность и своевременность обновления лежит на кураторах конкретных пакетов в каждом конкретном дистрибутиве.

Это не так в силу трёх причин:
1. Мейнтейнеры проверяют сопряжение компонент и вписываемость конкретной программы в дистрибьютив.
2. RPM (deb) контролирует все файлы, в то время как egg управляет только python.
3. Собрать rpm для чего-то на python'е не так сложно как кажется, а выгода огромна. К тому же, ничего не мешает самому стать “куратором” :)

Это все понятно. Но самом установиться не всегда хочется, а текущий куратор может пойти в отпуск, пропустить анонс о выходе новой версии либы или просто отвлечься от темы (или забить). Как ни крути, но все равно остается человеческий фактор.