[ON] Выпуск PyOxidizer для упаковки Python-проектов в самодостаточные исполняемые файлы

[rssbot]

Представлен первый выпуск утилиты PyOxidizer, позволяющей упаковать проект на языке Python в форму самодостаточного исполняемого файла, включающего интерпретатор Python и все необходимые для работы библиотеки и ресурсы. Подобные файлы могут выполняться в окружениях без установленного инструментария Python или независимо от наличия необходимой версии Python. PyOxidizer также может формировать статически связанные исполняемые файлы, которые не привязаны и к системным библиотекам. Код проекта написан на языке Rust и распространяется под лицензией MPL (Mozilla Public License) 2.0.

Проект основан на одноимённом модуле для языка Rust, позволяющем встраивать Python-интерпретатор в программы на Rust для выполнения в них Python-скриптов. PyOxidizer теперь вышел за рамки дополнения для Rust и позиционируется как доступный для более широкой аудитории инструмент для формирования и распространения самодостаточных пакетов с Python. Для тех кому не нужно распространять приложения в виде исполняемого файла, PyOxidizer предоставляет возможности по генерации библиотек, пригодных для связывания с любыми приложениями для встраивания в них интерпретатора Python и необходимого набора расширений.

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

Применение предложенных сборок также положительно сказывается на производительности - сгенерированные в PyOxidizer файлы запускаются быстрее, чем при использовании системного Python за счёт исключения импорта и определения базовых модулей. В PyOxidizer модули импортируются из памяти - все встроенные модули сразу загружаются в память и затем используются без обращения к диску). В тестах время запуска приложения при использовании PyOxidizer сокращается примерно в два раза.

Из уже существующих похожих проектов можно отметить: PyInstaller (распаковывает файл во временный каталог и импортирует модули из него), py2exe (привязан к платформе Windows и требует распространения нескольких файлов), py2app (привязан к macOS), cx-freeze (требует отдельной упаковки зависимостей), Shiv и PEX (формируют пакет в формате zip и требует наличия Python в системе), Nuitka (компилирует код, а не встраивает интерпретатор), pynsist (привязан к Windows), PyRun (проприетарная разработка без пояснения принципов работы).

На текущем этапе развития в PyOxidizer уже реализована основная функциональность по генерации исполняемых файлов для Windows, macOS и Linux. Из пока недоступных возможностей отмечается отсутствие типового сборочного окружения, невозможность генерации пакетов в форматах MSI, DMG и deb/rpm, проблемы с упаковкой проектов, включающих сложные расширения на языке Си, отсутствие команд для сопровождения доставки ("pyoxidizer add", "pyoxidizer analyze" и "pyoxidizer upgrade"), ограниченная поддержка Terminfo и Readline, отсутствие поддержки выпусков отличных от Python 3.7, отсутствие поддержки сжатия ресурсов, невозможность кросс-компиляции.


Источник: https://www.opennet.ru/opennews/art.shtml?num=50957
(opennet.ru, основная лента)

[Bizdelnick]

Что, опять? Сколько уже таких костылей было… Но главное — никто не в состоянии объяснить зачем они нужны.

[FlySnake]

Что, опять? Сколько уже таких костылей было… Но главное — никто не в состоянии объяснить зачем они нужны.

Нужны чтобы избавиться от геморроя с зависимостями и упростить дистрибьюцию. Пока староверы люто любят распил всего и вся на динамически либы с зависимостями, языки типа go завоёвывают мир возможностью упаковать всё в 1 исполняемый файл без зависимостей и геморроя. Хорошо это или плохо - каждый сам пусть решает.

[Bizdelnick]

Нужны чтобы избавиться от геморроя с зависимостями и упростить дистрибьюцию.

Для этого есть менее помоечные языки, есть virtualenv, в конце концов.

Пока староверы люто любят распил всего и вся на динамически либы с зависимостями, языки типа go завоёвывают мир возможностью упаковать всё в 1 исполняемый файл без зависимостей и геморроя.

Во-первых, я, хоть режьте меня, не понимаю, почему так принципиально, чтобы файл был именно один. Чем десяток файлов в каталоге хуже?
Во-вторых, геморрой начинается чуть позже, когда в одной из статически слинкованных либ обнаруживают дыру. И — вперёд, пересобирать всё, если, конечно, вообще кто-нибудь вспомнит, что эта либа там была. Но да, это не является проблемой при современном воркфлоу, если Вы понимаете, о чём я.

[FlySnake]

Ок, если что не я начал холивар

Для этого есть менее помоечные языки, есть virtualenv, в конце концов.

Я бы воздержался от оценок типа "помоечные языки". И во-вторых virtualenv это не про дистрибьюцию, а про локлаьную установку и разруливание зависимостей. По мне весьма стрёмное решение в том виде как есть, но кому как. Есть pipenv теперь хотя бы.

Во-первых, я, хоть режьте меня, не понимаю, почему так принципиально, чтобы файл был именно один. Чем десяток файлов в каталоге хуже?
Во-вторых, геморрой начинается чуть позже, когда в одной из статически слинкованных либ обнаруживают дыру. И — вперёд, пересобирать всё, если, конечно, вообще кто-нибудь вспомнит, что эта либа там была. Но да, это не является проблемой при современном воркфлоу, если Вы понимаете, о чём я.

Там где можно собрать 10 файлов в каталоге можно их же собрать и в 1. Выскрести все нужные динамически либы (или собрать отдельными шагами) и запаковать в архив не менее геморойно чем слинковаться статически, причём нет ни малейшего смысла тащить динамические либы в архиве ради одного приложения - это как бы defeats the purpose динамической линковки. Получается никакимх преимуществ кучи библиотек в архиве перед одним исполняемым файлом, так почему не делать сразу один файл?

Аргумент про обновления в случае дыр имеет фатальный недостаток. Если приложение поддерживается, то критические дыры во всяких openssl разработчик будет исправлять сборкой с новой версией и пушем её в нужные репы (будь то флэтпак какой-нить или оффициальная репа дистрибутива где за пакетом следит мейнтейнер). А если приложение заброшено и не поддеживается, то обновления зависимостей без обновления приложения рано или поздно приведёт к его поломке и выпиливанию из всех возможных репозиториев. Тут не нужно падать в крайности и пихать mc в докер, но для многих пользовательских приложений удобнее и разработчику и юзеру распространять бинарь без зависимостей (будь то статическая линковка, флэтпак или докер). Есть и тёмная сторона, когда каждое второе "десктоп" приложение на электроне и у каждого своя копия хрома с нодой в памяти - это даже на современных компах не алё, но эта фигня с электроном сама по себе нездоровая и подпирать её костылями из динамической линковки с системным браузером так себе идея.

[Bizdelnick]

И во-вторых virtualenv это не про дистрибьюцию, а про локлаьную установку и разруливание зависимостей. По мне весьма стрёмное решение в том виде как есть, но кому как. Есть pipenv теперь хотя бы.

Ну не знаю, я в сортах env'ов не разбираюсь. В любом случае, там хотя бы не будет накладных расходов из-за распаковки при каждом запуске.

Там где можно собрать 10 файлов в каталоге можно их же собрать и в 1.

Можно даже в 0,5. Но зачем? Чтобы запускалось ещё медленнее? (Я про питон, а не про статическую линковку.)

Аргумент про обновления в случае дыр имеет фатальный недостаток. Если приложение поддерживается, то критические дыры во всяких openssl разработчик будет исправлять сборкой с новой версией и пушем её в нужные репы (будь то флэтпак какой-нить или оффициальная репа дистрибутива где за пакетом следит мейнтейнер). А если приложение заброшено и не поддеживается, то обновления зависимостей без обновления приложения рано или поздно приведёт к его поломке и выпиливанию из всех возможных репозиториев.

А Вы предпочитаете использовать дырявый софт? К тому же обновления безопасности не ломают обратную совместимость. В таких библиотеках, как openssl, это вообще не чаще, чем раз в 5 лет происходит, и ещё несколько лет потом продолжает поддерживаться старая версия. И в нормальных дистрибутивах ничто не мешает держать одновременно несколько версий библиотеки:

Shell

$ ls /usr/lib/x86_64-linux-gnu/libssl.so.*
/usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
/usr/lib/x86_64-linux-gnu/libssl.so.1.0.2
/usr/lib/x86_64-linux-gnu/libssl.so.1.1
$

[Kopilov]

Эх, а я всё кофейным кактусом давлюсь… ну вы поняли ☺
И эта гадость, реально, вызывает привыкание!
«Именно поэтому мы решили запретить у нас это [жамалистовое] дерево!»
Уже под разными соусами ем (Glassfish, Ceylon были, теперь вот Matlab), и всё больше хочется