Что такое cx freeze
cx_Freeze + virtualenv = баги и зигзаги
Установка cx_Freeze
Не подходит, потому что устанавливает cx_Freeze для Python2.
Попробуем через pip3:
Однако, как бы не так. На Убунте (другие ОС пока не пробовал) это вызывает следующую ошибку (прошу прощения за картинки. На момент написания статьи сделать текстовый копипаст оказалось затруднительно по причинам из серии «это долгая история»):
Порывшись по StackExchange, я понял, что без установки из исходников дело не обойдётся.
Скачал. Распаковал. Запустил:
Снова порылся по StackOverflow. Пришлось залезть в setup.py и заменить там строчку:
Попробовал запустить снова — и установилось! Ура!
На заметку
Собираем скрипт!
где main.py — имя основного (запускаемого) скрипта, а build — папка, куда пойдут исполняемый файл и библиотеки.
Следует учитывать, что в отличие от, скажем, компиляторов C++, cx_Freeze не отлавливает ошибки. Поэтому он может прекрасно всё собрать, но при запуске исполняемого файла посыпятся исключения, причём в довольно неразборчивом формате. Советую потестить код, пока он ещё питонический.
Думаю, что оптимизация кода для сборки в исполняемый файл — тема для отдельного обсуждения, ибо при сборке могут вылезти проблемы, которых при запуске скрипта через интерпретатор Python просто не было. Здесь расскажу об одной (слава богу, одной! больше просто не возникло) такой проблеме.
Мой скрипт обращается к внешним файлам с настройками. Но при запуске из исполняемого файла он почему-то стал воспринимать имя скрипта, как одну из папок на пути к файлу настроек. То есть, если собранный исполняемый файл под названием main находится в /tmp/001, а файл настроек — в /tmp/001/sett, то скрипт думал, что файл настроек на самом деле располагается в /tmp/001/main/sett. Что, естественно, бред. А если же запустить питоновый скрипт — этой проблемы нет.
Дело в том что я в начале своих программ зачастую впихиваю следующую строчку:
Эту переменную я потом использую при задании путей к файлам, которые всегда находятся в одном и том же месте относительно скрипта: файлы настроек, сохранения, токены, коды приложений, и т. д. Таким образом я гарантирую, что программа считает файл из правильного места вне зависимости от того, откуда она была запущена (например, из другой папки или через демона).
Собранные через cx_Freeze скрипты обычно либо неправильно интерпретируют глобальную переменную __file__, либо вообще ее не знают. Последнее как раз произошло, когда я попробовал собрать и запустить исполняемый файл из простенького тестового скрипта:
Проблема оказалась известной. Достаточно было слегка пропатчить мою программу:
В результате, всё завелось с полпинка! Отлично. Простая часть завершена! Переходим к повторению всего этого в виртуальной среде!
Ох уж эти виртуальные среды!
Если вы не пользуетесь virtualenv, полагаю, вас не очень заинтересует дальнейшее чтение этой статьи. Особенность заключается не только в установке cx_Freeze в среду, но и в запуске его таким образом, чтобы он пользовался именно зависимостями из среды, а не системными.
На заметку
Пользоваться средой в шелле (запускается через «source env/bin/activate») нам не придётся. Я пробовал, эффекта это не дало.
Установка
/path/to/my/project/env/bin/python3 setup.py install
Не очень удобно. Пришлось прописывать путь к интерпретатору Питона в нашей среде. Но всё установилось.
Сборка
Однострочный метод, описанный выше, здесь не пройдёт. Нужно использовать другой — через установочный файл.
Файл этот, в краткой форме, которая мне была вполне достаточна, выглядит следующим образом:
Самое главное здесь, это задать MAIN_SCRIPT_NAME, которая соответствует имени главного файла нашей программы.
Помещаем этот скрипт в папку проекта и переходим туда. Запускаем:
jenyay.net
Софт, исходники и фото
Создание запускаемых файлов из скриптов на языке Python с помощью cx_Freeze
Содержание
1. Введение
Именно это и делает библиотека cx_Freeze, причем такой прием эта библиотека умеет применять для Windows, Linux и Mac OS. Эта статья будет посвящена использованию данной библиотеки. На простейших примерах мы рассмотрим основы работы с этой библиотекой cx_Freeze и различные сценарии ее использования.
Все примеры в этой статье тестировались на Python 3.6 и cx_Freeze 5.0.2. cx_Freeze пока еще умеет работать с Python 2.7, но судя по коммитам на github, следующая версия cx_Freeze 6 будет работать только с Python 3.5 и выше.
2. Установка
Устанавливается cx_Freeze стандартно через pip. Если вы хотите установить cx_Freeze глобально для всех пользователей системы, то нужно выполнить в консоли команду
Разумеется, для этого у вас должны быть права администратора, и консоль должна быть запущена от администратора.
Или вы можете установить cx_Freeze только для вашего пользователя, тогда админские права не понадобятся:
В реальном проекте идеологически более верно установить cx_Freeze внутри virtualenv, но в этом случае могут быть некоторые проблемы (например).
3. Первый пример
Теперь, когда cx_Freeze установлен, можно приступать к изучению возможностей этой библиотеки. Все примеры из статьи вы можете найти на github. Примеры последовательно пронумерованы в том порядке, как они описаны в статье. Приложение, которое мы будем упаковывать в запускаемые файлы, будет называться example.py.
Для начала создадим простейший python-скрипт с именем example.py, который не импортирует никакие модули (Example 01 на github):
if __name__ == ‘__main__’ :
print ( ‘Hello world!’ )
Скорее всего нет смысла описывать, что делает данный скрипт. 🙂 Желающие убедиться, что скрипт работает, могут выполнить команду:
Если у вас установлено несколько версий Python, то под Windows можно воспользоваться утилитой py и явно указать номер версии интерпретатора:
Давайте упакуем наш очень полезный скрипт в запускаемый файл, который можно будет передать пользователю. Для этого создадим файл setup.py со следующим содержимым:
executables = [ Executable ( ‘example.py’ ) ]
Имя скрипта для сборки может быть произвольным, но обычно принято называть его setup.py, и мы будем придерживаться этого правила. Те, кто создавал Python-пакеты с помощью утилит distutils или setuptools, увидят в работе с cx_Freeze что-то знакомое.
Конструктор класса Executable может принимать достаточно большое количество параметров. Обязательным параметром является только имя запускаемого python-файла. Если ваша программа состоит из большого количества скриптов, то указывать нужно на тот файл, который запускал бы пользователь, если бы он запускал приложение из исходников. Полностью конструктор класса Executable выглядит следующим образом (класс описан в файле freezer.py исходников cx_Freeze):
Некоторыми из этих параметров мы еще воспользуемся, а некоторые останутся за рамками статьи, назначение многих из них понятно из названия переменных.
Чтобы создать запускаемый файл, запустим консоль и перейдем в папку, где лежит файл setup.py. Затем нужно выполнить команду
На экран будет выведено достаточно много теста:
В довольно большом логе работы можно увидеть, какие модули Python попали в сборку, а каких по мнению cx_Freeze не хватает. Чаще всего на этот вывод можно не обращать внимания, если нет каких-либо ошибок.
После запуска скрипта сборки, если все прошло успешно (если нет сообщений об ошибках), рядом с файлами example.py и setup.py должна появиться папка build, а в ней папка, имя которой зависит от версии Python. Например, если сборка запускалась с помощью 32-битной версии интерпретатора Python 3.6, то будет создана папка exe.win32-3.6, а в ней огромное количество файлов и папок.
По умолчанию cx_Freeze в архив помещает одиночные модули, а пакеты помещает в корень папки сборки. В данный момент в сборку попало очень много лишних модулей, который на самом деле не используются в программе. Например, среди модулей можно увидеть unittest, logging, xml, urllib и другие, которые явно не используются в нашей простой программе. Скоро мы научимся удалять лишние модули из сборки и вручную добавлять необходимые.
4. Добавление файлов Microsoft Visual C++ Redistributable
Интерпретатор Python компилируется под Windows с помощью Microsoft Visual C++, поэтому для того, чтобы пользователи могли запускать собранное вами приложение, у них должен установлен Microsoft Visual C++ Redistributable Package, который они должны скачать с сайта Microsoft. Это не очень удобно. Ситуация усугубляется тем, что разные версии Python компилируются с помощью разных версий компилятора.
Чтобы решить эту проблему вы можете поставлять с вашим дистрибутивом необходимые файлы *.dll. Например, для Python 3.6 достаточно скопировать файл vcruntime140.dll из папки с установленным Python. Для того, чтобы не делать эту вручную, cx_Freeze может делать это за вас, для этого надо добавить новый для нас параметр в функцию setup скрипта сборки setup.py. Исправленный скрипт сборки теперь будет выглядеть следующим образом (Example 02):
executables = [ Executable ( ‘example.py’ ) ]
В функцию setup был добавлен новый параметр options, который должен быть словарем. Этот словарь содержит вложенные словари, описывающие особенности сборки для разных операционных систем и типов сборки (cx_Freeze кроме запускаемых файлов может создавать инсталяторы). Все возможные параметры можно найти в документации, некоторые из этих параметров мы еще будем использовать в дальнейшем.
Но в последних версиях cx_Freeze есть некоторые непонятные моменты, связанные с этим параметром. По идее после запуска нового скрипта сборки с помощью команды
5. Избавляемся от лишних модулей
Как мы видим, несмотря на то, что наш исходный скрипт Hello World явно не импортирует никакие модули, в сборку попало достаточно много файлов *.pyc и *.pyd. Некоторые из них нам явно не нужны (например, unittest, logging и другие). Полный размер сборки сейчас составляет 9.05 МБ, что для простого Hello World кажется излишним, хотя при современных размерах жестких дисков скорее всего не будет проблемой.
Чтобы исключить какие-либо модули из сборки, в словарь параметров build_exe нужно добавить ключ excludes, значением которого должен быть список строк с именами модулей, которые нужно исключить. Давайте для начала исключим модули, которые нам явно не нужны. Добавим параметр excludes с небольшим списком модулей (Example 03):
executables = [ Executable ( ‘example.py’ ) ]
После сборки заходим в папку build\exe.win32-3.6\ или аналогичную ей и видим, что количество файлов и папок заметно уменьшилось:
В архиве python36.zip количество файлов тоже немного уменьшилось:
В реальном проекте, возможно, стоит на этом остановиться и не рисковать сломать программу, удаляя более мелкие модули. Но поскольку у нас очень простая программа, мы можем пойти дальше и путем перебора попробовать удалить как можно больше ненужных модулей. Через несколько (десятков?) итераций удаления и восстановления модулей получился следующий скрипт сборки (Example 04):
executables = [ Executable ( ‘example.py’ ) ]
После его запуска с помощью команды python setup.py build сборка будет выглядеть следующим образом:
А в архиве python36.zip остались лишь следующие модули:
В архиве осталось всего 19 файлов из 100 первоначальных. Теперь сборка занимает 3.7 МБ. По-моему, неплохо. Но это еще не все.
executables = [ Executable ( ‘example.py’ ) ]
Запускаем сборку и смотрим на ее результат:
Осталось всего лишь три файла!
Указанные в скрипте сборки модули переместились в файл python36.zip:
6. Наводим красоту в сборке
Давайте изменим файл setup.py, таким образом, чтобы создаваемая сборка помещалась, например, в папку build_windows рядом со скриптами. Для этого снова нужно добавить новый параметр в словарь build_exe. Этот параметр тоже должен называться build_exe и хранить строку с папкой, куда должна помещаться сборка (Example 06):
executables = [ Executable ( ‘example.py’ ) ]
Теперь после создания сборки рядом с файлами example.py и setup.py появится папка build_windows, где будет находиться созданная сборка, ничем не отличающаяся от предыдущего примера.
Запускаем сборку и видим, что в папке build_windows вместо example.exe появился файл hello_world.exe:
7. Добавление модулей в сборку
До сих пор мы только исключали лишние модули из создаваемой сборки с помощью параметра excludes словаря build_exe. Однако, импорт модулей в Python может происходить не только с помощью оператора import, но и динамически по имени модуля с помощью функции ‘_import_‘, а может быть импорт будет осуществляться с использованием сложной логики, когда cx_Freeze не сможет понять, что нужно добавить какой-то модуль в сборку.
Давайте изменим наш пример таким образом, чтобы он импортировал модуль json таким образом, что cx_Freeze об этом не узнает (Example 08):
if __name__ == ‘__main__’ :
module = __import__ ( ‘json’ )
print ( ‘Hello world!’ )
Скрипт сборки setup.py пока останется неизменным. Запустим сборку с помощью команды python setup.py build, ошибок при этом не возникнет, будет создана сборка в папке build_windows.
Однако если теперь мы запустим созданный файл hello_world.exe, то в консоль будет выведено информация об исключении:
Traceback (most recent call last):
File «C:\. \Python36\site-packages\cx_Freeze\initscripts\__startup__.py», line 14, in run
module.run()
File «C:\. \Python36\site-packages\cx_Freeze\initscripts\Console.py», line 26, in run
exec(code, m.__dict__)
File «example.py», line 5, in
ModuleNotFoundError: No module named ‘json’
На указанные пути обращать внимания не будем. Для нас сейчас главное, что мы получили ошибку времени исполнения. Надо ее исправлять, а именно нужно добавить модуль json в сборку.
Если для исключения модулей из сборку предназначен параметр excludes, до для включения модуля в сборке используется параметр includes, который тоже должен содержать список модулей, которые нужно добавить в сборку. Параметр includes так же должен входить в словарь build_exe. Добавим модуль json в этот список (Example 08-1):
Создаем сборку, заходим в папку build_windows и видим, что в ней появилась папка с именем json:
Но не спешим радоваться. При попытке запустить hello_world.exe мы получим новую ошибку:
Теперь не хватает модуля для работы с регулярными выражениями re. Если мы посмотрим внимательнее на наш предыдущий файл setup.py, то увидим, что этот модуль мы исключили из сборки с помощью параметра excludes, а этот модуль, оказывается, используется в модуле json. Если мы исключим модуль re из списка excludes, то это тоже не решит проблему, окажется, что еще нужны другие модули, которые вы выкинули из сборки. Я же предупреждал, что не надо увлекаться удалением модулей. Постепенно удаляя имена модулей из списка excludes можно добиться работоспособной сборки. Новый файл setup.py теперь выглядит следующим образом (Example 08-2):
Из списка excludes были убраны следующие модули: re, functools, operator, keyword, heapq, reprlib, weakref.
Создаем сборку и получаем теперь уже работоспособное приложение. Если мы зайдем в папку build_windows, то увидим, что внешне ничего не изменилось, в ней из перечисленных модулей значится только папка json, остальные модули были помещены в архив python36.zip:
И для аккуратности сделаем так, чтобы модуль json тоже был помещен в архив python36.zip, добавим строку ‘json’ в параметр zip_include_packages (Example 08-3):
Теперь сборка выглядит аккуратно и состоит всего из трех файлов:
А в архиве python36.zip появился модуль json:
8. Сборка нескольких запускаемых файлов
Сделаем два простых скрипта в одной папке (Example 09).
if __name__ == ‘__main__’ :
print ( ‘Hello world 01!’ )
if __name__ == ‘__main__’ :
print ( ‘Hello world 02!’ )
Запускаем сборку и видим, что в папке build_windows появились файлы hello_world_01.exe и hello_world_02.exe:
А в архиве python36.zip имеется модуль json, который нужен только для hello_world_01.exe:
Компиляция Python
Предположим, вы разработали приложение или библиотеку на Python и уже готовитесь передать его / её заказчику. И в этот момент возникают вопросы, о которых многие даже не задумываются.
Во-первых, так может оказаться, что вы разработали супер крутой алгоритм, которого ни у кого нет, и показывать его хочется только избранным.
И, наконец, хочется, чтобы конечное приложение работало быстрее, чем в среде разработки.
И вот тут настало время скомпилировать Python-код. Меня зовут Руслан, я старший разработчик компании «Цифровое проектирование». Сегодня я расскажу, как выбрать тот самый компилятор из множества доступных.
AOT/JIT
Компиляция – это сборка программы, включающая: трансляцию всех модулей программы, написанных на языке программирования высокого уровня, в эквивалентные программные модули на низкоуровневом языке, близком к машинному коду, или на машинном языке и сборку исполняемой программы. Существует два вида компиляции:
AOT-компиляция (ahead-of-time) – компиляция перед исполнением программы. Т.е. программа компилируется один раз, в результате компиляции получается исполняемый файл.
Бенчмарк
Так как одной из целей является ускорение, необходимо оценить, насколько быстро работает скомпилированный код. В качестве бенчмарка будем использовать pyperfomance. К сожалению, pyperfomance не подошел для Cython и Pythran, потому что не позволяет визуализировать все возможности языка. Ускорения для Cython без модификации кода получить не удалось, а Pythran не умеет в пользовательские классы. Для них воспользуемся вычислением числа пи:
Эксперименты будем проводить на процессоре Intel Core i7 10510U. На CPython 3.9.7 время вычисления числа пи до 100.000.000 знака заняло 5.82 секунды.
AOT-компиляция Python
PyInstaller
PyInstaller упаковывает приложения Python в автономные исполняемые файлы в Windows, GNU / Linux, Mac OS X, FreeBSD, Solaris и AIX.
Устанавливается через pip:
pip install pyinstaller
После установки для создания исполняемого файла достаточно выполнить команду:
В результате будет создано:
build/ – директория с метаданными для сборки исполняемого файла;
dist/ – директория, содержащая все зависимости и исполняемый файл.
Сборку приложения можно настроить с помощью параметров командной строки:
—name – изменение имени исполняемого файла (по умолчанию, такое же, как у сценария);
—onefile – создание только исполняемого файла (по умолчанию, папка с зависимостями и исполняемый файл);
—hidden-import – перечисление импортов, которые PyInstaller не смог обнаружить автоматически;
—add-data – добавление в сборку файлов данных;
—add-binary – добавление в сборку бинарных файлов;
—exclude-module – исключение модулей из исполняемого файла;
У PyInstaller есть ограничения. Он работает с Python 3.5–3.9. Поддерживает создание исполняемых файлов для разных операционных систем, но не умеет выполнять кросскомпиляцию, т. е. необходимо генерировать исполняемый файл для каждой ОС отдельно. Более того, исполняемый файл зависит от пользовательского glibc, т. е. необходимо генерировать исполняемый файл для самой старой версии каждой ОС.
PyInstaller знает о многих Python-пакетах и умеет их учитывать при сборке исполняемого файла. Но не о всех. Например, фреймворк uvicorn практически весь нужно явно импортировать в файл, к которому будет применена команда pyinstaller. Полный список поддерживаемых из коробки пакетов можно посмотреть здесь.
Cython
Ставится Cython через pip:
pip install Cython
Рассмотрим его работу на примере с вычислением числа пи:
Немного модифицируем нашу функцию:
Cython → C:
Компилируем С-шный код:
И замеряем время на бенчмарке: 3,66 секунды.
А что делать, если в нашем проекте несколько файлов, которые нужно скомпилировать? Тогда нужно использовать так называемый сценарий сборки. С его помощью можно модернизировать сборку в зависимости от операционной системы, указывать несколько файлов, которые необходимо скомпилировать, и многое другое.
Создадим файл build.py:
Запустим: python build.py build_ext –-inplace
В результате будет сгенерирован .so/.dll файл.
Nuitka
Ставится через pip:
pip install nuitka
Для генерации исполняемого файла достаточно выполнить команду:
Для компиляции модуля:
Для компиляции пакета:
Pythran
Pythran – статический компилятор Python, позиционирующий себя как ориентированный на научные вычисления и использующий преимущества многоядерных процессоров и блоков инструкций SIMD. Он транслирует Python-код, аннотированный описаниями интерфейса, в C++. До версии 0.9.5 (включительно) Pythran поддерживал Python 3 и Python 2.7. Последние версии поддерживают только Python 3.
pip install pythran
Генерируем бинарный файл .so:
Pythran по умолчанию не умеет в пользовательские классы, поэтому при попытке их компиляции будет выброшена ошибка:
Top level statements can only be assignments, strings,functions, comments, or imports
Добавим комментарий аннотации функции:
Скомпилируем и бенчмарк выдает 0,00007 секунды.
cx-Freeze
Ставится с помощью pip:
pip install cx_Freeze
Для генерации исполняемого файла достаточно выполнить команду:
Сборку можно настроить с помощью параметров командной строки:
Также возможно использование сценария сборки, например, так:
Сборка исполняемого файла:
python setup.py build
JIT-компиляция Python
JIT-компиляция не позволяет скрывать исходники или создавать автономный исполняемый файл, но дает возможность значительно ускорить выполнение программы.
PyPy
компилятор байт-кода, отвечающий за создание объектов кода Python из исходного кода пользовательского приложения;
оценщик байт-кода, ответственный за интерпретацию объектов кода Python;
стандартное объектное пространство, отвечающее за создание и управление объектами Python, видимыми приложением.
PyPy поддерживает сотни библиотек Python, включая NumPy.
Основные особенности (сравнение с CPython):
Скорость. При выполнении длительно выполняющихся программ, когда значительная часть времени тратится на выполнение кода Python, PyPy может значительно ускорить ваш код.
Использование памяти. Программы Python, требующие много памяти (несколько сотен Мб или более), могут занимать меньше места, чем в CPython. Однако это не всегда так, поскольку зависит от множества деталей. Также базовый уровень потребления оперативной памяти выше, чем у CPython.
Скачать PyPy можно с здесь. После скачивания PyPy готов к запуску после распаковки архива. Если необходимо сделать PyPy доступным для всей системы, достаточно поместить символическую ссылку на исполняемый файл pypy в /usr/local/bin. Также можно поставить с помощью pyenv.
PyPy работает на Mac, Linux (не все дистрибутивы) или Windows.
Для запуска кода с помощью PyPy вместо команды python3 (как c помощью CPython) достаточно воспользоваться командой pypy3:
Pyston
В Pyston поддерживаются все возможности CPython, в том числе C API для разработки расширений на языке Си. Среди основных отличий Pyston от CPython помимо общих оптимизаций выделяется использование DynASM JIT и inline-кэширования.
Заключение
Итак, мы рассмотрели 5 фреймворков AOT-компиляции Python. Для любителей аналитики, ниже приведена таблица со сравнительным анализом.
PyInstaller
Cython
Nuitka
Pythran
cx-Freeze
Генерация автономных исполняемых файлов
Компиляция python-модуля в исполняемый файл, совместимый с CPython