Есть небольшой проектик — extension для ванильного питона. Начал делать пакет для дистрибьюции — столкнулся с кучей проблем, интернет читал, всех ответов не нашел. Понимаю, что тема узкая, но вдруг кто-то сталкивался.
Итак:
проблема усугублена тем, что extension только для windows и соответственно распространять в исходниках пакет бессмысленно, так как на стандартной windows машине их не собрать. Соответственно, приходится делать бинарный дистрибутив ( тут отдельная песня ). Изрядно помучавшись, у меня получилось сделать egg, который нормально устанавливается с локального каталога ( через easy_install ). Теперь я хочу опубликовать его на pypi. Но pypi у меня отказывается брать egg. В документации они пишут, что pypi поддерживает wheel ( это еще интересная песенка о том, чем отличаются egg и wheel и зачем два разных одинаковых формата пакетов ). Ок, научился собирать wheel и он нормально загурзился на pypi и ставится через pip. Поэтому, первый вопрос:
1) На pypi вообще нельзя загузить egg? Но ведь easy_install благополучно с ним работает? Или он только source дистрибутивы умеет скачивать? И форма загрузки файлов через web на pypi тоже имеет тип файла egg, но загружать их также отказывается. Т.е egg вообзе нельзя загружаит или просто яйцо у меня неправильно получилось, например, какого нибудь параметра не хватает ( на pypi расширенной диагностики я не нашел ) ?
2) В целом Б-г с wheel сами, жить бы было можно, но у меня с ними никак не получается исправить один баг:
Мое расширение представляет собой один модуль ( pyd ) и в питоновских скриптах я его хочу использовать просто как import mymodule. При использовании egg все норм: в каталоге site-packages создаетсся подкаталог с распакованным содержимым egg ( я ставлю zip_safe=False), а в корне катлога в файле easy_install.pst прописывается к нему путь. В итоге питон находит модуль. При установке wheel ( собранного через тот же setup.py ) файлы распаковываются прямо в корень site-packages. Вроде все работает — но меня это бесит )), не хочется засирать общее пространство. В итоге получается дилемма: с одной стороны я научился вроде делать нормально устанавливаемые яйца, но не могу их выложить на pypi, с другой стороны wheel работают не так как мне хочется (((.
В порядке холивара, вся эта система какой то лютый ****** . Вроде как питон всегда провозглашал некие здравые подходы к разработке, все эти "просто лучше чем сложно", "явное лучше чем не явное" и.т.п, но с рапространениев пакетов что то явно пошло не так...
Да, проект с открытым кодом и абсолютно некоммерческий, так что если есть желающие поломать себе руки на голом энтузиазме, велкам!!!
в итоге, я конечно сделал нечто распространяющееся через pypi, но удовольствия что-то ен получил от этого процесса.
Куча всяких старнностей пожидает желающих собрать свой пакет для python а.
Могу дать совет на будущее: если собираетесь делать что-то на питоне для распространения, начинайте со сборочной системы. setuptools очень негибкая хрень, лучше сразу делать проект под ее требования, будет меньше боли потом.
Здравствуйте, pykd_team, Вы писали:
_>в итоге, я конечно сделал нечто распространяющееся через pypi, но удовольствия что-то ен получил от этого процесса. _>Куча всяких старнностей пожидает желающих собрать свой пакет для python а. _>Могу дать совет на будущее: если собираетесь делать что-то на питоне для распространения, начинайте со сборочной системы. setuptools очень негибкая хрень, лучше сразу делать проект под ее требования, будет меньше боли потом.
А смысл? Возня с пакетами была не ради того, чтобы как нибудь выложить, а ради того чтобы выложить именно в pypi, чтобы можно было во-первых сказать "пакет распространяется стандартным способом, жми pip install имя_пакета", а во вторых, чтобы пакет можно было прописывать в зависимости к другим пакетам. Собственно использование альтернативных способов размещения пакетом не решает данные вопросы.
За ссылку отдельно спасибо: никогда не знаешь что в нашем деле пригодится .
АУ>Вдогонку — модули и должны лежать в корне site-packages.
Вот это мне не нравится, у меня модуль тянет за собой несколько dll — не красиво будет все склыдавать прямо в корень. Придет второй такой же поросенок и получится уже свинарник . Я в итоге установил все как пологается, в отдельный каталог в site-packages, а чтобы все работало в __init__.py прописал процедуру импортирования.
АУ>И wheel, говорят, лучше, чем egg...
Я конечно все это читал . Но если посмотреть на внутренности, то wheel — это такой же zip файл как и egg, с очень похожей структурой каталогов. Так что говорить о каком то улучшении довольно странно. Тут такая история с egg умеет работать easy_install, но он старый и не умеет делать таких простых вещей как корректное удалени пакетов. Но зато есть новый pip он умеет все что нужно, но имеет некую прихоть — он хочет работать именно с wheel ами, а не с egg ами. В результате, получается что wheel лучше, потому что его поддерживает более лучший пакетный менеджер. Т.е. телега впереди лошади. ОТдельные вопросы вызывает факт отсутствия пакетных менеджеров в поставках питона. Это чем то напоминает ситуацию, когда нужно установить драйвер сетевой карты, скачав его с интернета .
Еще вопрос в догонку:
Как распространять дополнительные материалы ( примеры, документацию и.т.п) с пакетом?
Есть пакет, ставится в site_packages, вроде все более-менее работает. И есть несколько ( десятков ) маленьких скриптов — примеров, демонстрирующих работу с пакетом. Вопрос: куда их сложить. На первый взгляд, я вижу варианты:
1) сложить в подкаталог прямо в пакете. Но тогда не очень удобно пользоваться, чтобы запустить пример придется писать полный путь:
python путь_к_питону/lib/site_packages/my_packet/samples/sample1.py
в принципе сойдет, но может есть лучшее решение?
2) сложить в каталог Scripts
вот этого совсем не хочется. Scripts — это и так помойка, напихать туда еще толпу малонужных скриптов кажется сомнительной затеей.
3) куда да нибудь вне питона. Тут главное не понятно, как это сделать при установке через pip/easy_install.
.
. Но если посмотреть на внутренности, то wheel — это такой же zip файл как и egg, с очень похожей структурой каталогов. Так что говорить о каком то улучшении довольно странно. Тут такая история с egg умеет работать easy_install, но он старый и не умеет делать таких простых вещей как корректное удалени пакетов. Но зато есть новый pip он умеет все что нужно, но имеет некую прихоть — он хочет работать именно с wheel ами, а не с egg ами. В результате, получается что wheel лучше, потому что его поддерживает более лучший пакетный менеджер. Т.е. телега впереди лошади. ОТдельные вопросы вызывает факт отсутствия пакетных менеджеров в поставках питона. Это чем то напоминает ситуацию, когда нужно установить драйвер сетевой карты, скачав его с интернета 