Pull to refresh

Comments 18

Тоже вариант. С ним действительно проще собирается и тулзы нормально работают.
Но как-то больше понравилось как сама прога на Qt5 работает — быстрее запускается GUI.
А когда я начал собирать под Винду, все уже было написано — переписывать назад не хотелось :)
Я как-то пытался PyQt5 собрать, так и не получилось его ни к MinGW, ни к MS VS прикрутить(просил 2010, а под рукой были только 2012 и 2013).
А Python 3 не использую, потому что пару раз нарывался на то, что нужных библиотек под него нет.
Я ничего серьезного пока не пишу, но все равно неприятно.

Если важна скорость попробуйте PyPy
http://habrahabr.ru/post/87364/
> Я как-то пытался PyQt5 собрать…
Такая же картина, причем в pip есть целых два пакета (PyQt5 и python-qt5), которые либо не ставятся либо не собираются. Поэтому приходится качать готовый с сайта. До сих пор не понимаю, почему на том же самом сайте не захотели выложить SIP, который приходится руками собирать?

И вот эта магия «возьми SIP собранный в полнолуние с помощью MingW и плясок, добавь к нему PyQt5 с речного берега, потом щепотку нативного pyreadline, тщательно перемешай в ступе автоконфигом и т.п.» немного удручает.

PyPy надо посмотреть. Спасибо за наводку.
Пробовали его под виндой и в таких приложениях?
Я из-за этих причин, стараюсь вообще не касаться изучения С++ и использования Open Source на нем.
Есть более интересные способы прожить жизнь, чем неделями собирать софт из исходников.
Как исключение системы портов и портежей, сами понимаете в каких операционках, они на удивление стабильны.

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

ИМХО, исходный код должен быть в таком состоянии, чтобы человек мог его скачать, скачать необходимые библиотеки с дефолтных сайтов и собрать без головных болей и красных глаз. Да чтобы еще запустилось.

Ситуация напоминает середину 2000-х, когда на коне была Delphi 7. Выпускалась масса компонентов с намеренными ошибками, не зная языка подключить их не представлялось возможным. Только тут ошибки ненамеренные и поиск их не имея боевого опыта программирования не имеет смысла.

PyPy пока не знаю куда воткнуть. Думаю сайтик поднять в 2 экземплярах и покрутить его одновременно на оригинальном интерпретаторе и PyPy, посмотреть самому на скорость и стабильность. Но не знаю дойдут ли руки.
Мой опыт: приложение на Py3.4 и PyQt4 собирается cx_Freeze и запускается нормально. Правда там был какой-то баг в cx_Freeze, который исправили, но почему-то в официальный релиз на тот момент этот патч не попал. При этом исправленная версия была доступна на всем известном сайте. С PyQt5 собирать standalone-сборку честно не пробовал, надо будет проверить.
У меня тоже cx_freeze шел в лидерах — раньше остальных смог собрать прогу, но не рабочую. Видимо, я на этот баг и напоролся.
Я пробовал самостоятельно компилить патченую версию, но это превратилось в такую мороку.
Самое смешное, что cx_freeze единственный из тройки не поддерживает сборку в single-executable, т.к. автору не нравятся те хаки, которые для этого применяют py2exe и pyinstaller. Из-за этого и появилась вторая часть моего рецепта — превращение в single exe.
Да, я когда этот вопрос изучал, выделил cx_freeze как самый адекватный проект, он на тот момент умел собирать сложные штуки, типа pyqt/pyside+numpy+scipy+matplotlib и т.п. Это мне и было нужно. Помню, пробовал pyinstaller, переплевался и выкинул в мусорку.

cx_freeze не умеет собирать single exe, это да, но я в своё время проникся идеей не делать так, хотя бы потому что мой проект зависел от разных dll, и я их периодически обновлял, не пересобирая само приложение, что оказалось очень удобно.
Самое смешное, что cx_freeze единственный из тройки не поддерживает сборку в single-executable, т.к. автору не нравятся те хаки, которые для этого применяют py2exe и pyinstaller.
В свое время нам почему-то не подошел cx_Freeze, очень возможно, что как раз поэтому: требовался единственный экзешник.

Посмотрел в том проекте сейчас: для деплоймента в GNU/Linux я таки-писал спек-файл для PyInstaller, а для венды/вайна — setup.py для py2exe, хотя он и не понимал .egg-bundles («does not eat eggs for breakfast»), т.е. пришлось писать unpack_egg(), а потом еще самостоятельно сжимать бинарник UPX'ом.

Не помню точно, почему не унифицировал: в комментарии написано, что Windows is currently not supported, and would require changing «excludes» list below (в обоих случаях я старался ужаться по минимуму, поэтому скрупулезно выкидывал ненужные либы). Возможно, py2exe, несмотря на недостатки, позволял получить файл меньшего размера.
Используйте Nuitka. Сейчас это лучшая из альтернатив (ИМХО, конечно). Я пробовал собирать небольшое приложение на PyQt5, всё прошло просто и без проблем.

nuitka.net
Была такая мысль, тоже его попробовал, но не задалось.
Может есть хороший мануал или какие нюансы его использования?
Так нет никаких нюансов :) просто запускаете из консоли с нужными параметрами и всё. Я своё приложение собирал так:

nuitka --standalone --recurse-all --recurse-stdlib --windows-disable-console --windows-icon=ICON_FILE --recurse-directory=PROJECT_DIR

ICON_FILE и PROJECT_DIR надо заменить соответствующими путями.

Если будете использовать какие-то очень сложные модули, есть вероятность, что их dll'ки придётся вручную в каталог с exe'шником положить, чтобы всё работало. В случае с PyQt5, повторюсь, работает без этого.
Вы со вторым питоном использовали?
У меня не взлетело (:
Error, need to find Python2 executable under C:\Python26 or C:\Python27 to execute scons which is not Python3 compatible.
Ну так установите соответствующую версию Nuitka.
Лично мне помогла установка соотв. версии Python параллельно с тройкой, для которой и собиралось.
Я ставил через pip:
python -m pip install nuitka
Питон в системе только 3, чтобы не мешать либы.
На эту папку можно натравить создаватель инсталляторов, типа Inno Setup и получить msi. В моем случае, надо было обеспечить работоспособность программы с минимальными правами пользователей — точно без права установки либ.

MSI не обязательно требуют права администратора, но при этом удобней (и солидней :) ) для пользователя чем просто самораспаковывающийся архив. Просто при создании инсталляционного пакета, выберается режим, в котором оговаривается что установка будет по-умолчанию производится не в Program Files/MyProgramName, а в AppData/Local/MyProgramName (как и делают всякие Дропбоксы, Хромы, и т.д). Ну и ярлыки чтобы не в ProgramData закидывались, а в локальную для пользователя папку.

Главное понимать, что такая локальная инсталляция всегда менее безопасна чем обычная: так исполняемые файлы установленного софта доступны для редактирования кем и чем угодно — в конторы с требованиям по безопасности такой софт лучше не ставить (то же и к самораспаковывающимся архивам относится; особенно если не запихивать их потом руками в Програм Файлс).

Не знаю как это делается при использовании Inno Setup, но вот при помощи WiX Installer (набор опенсорсных утилит от Microsoft) я такие инсталляторы свободно создавал когда требовалось — мануалы на эту тему в сети найти не сложно. Да и может еще какие новые графические конфигураторы для WiX за это время появились в дополнение к тому что был несколько лет назад (не проверял). В любом случае правильный MSI создать не сложно — более-менее на уровне с другими системами инсталляции. А преимуществах — и удобство юзера, и автоматизация процессов инсталляции/деинсталляции и гибкость.
Спасибо. Интересный вариант.
Sign up to leave a comment.

Articles