Превращение Apache Superset в приложение для macOS

Я активный пользователь, а также пишу код для Apache Superset. Запуск Superset на моем MacBook — единственная причина установить Docker (все еще виртуальную машину внутри?), Который я считаю слишком тяжелым.

Superset возлагает большую часть тяжелой работы на сторону базы данных, я подумал, может быть, есть какая-то возможность иметь Superset.app, чтобы упростить использование Superset на моем MacBook.

Мой технический стек в основном бэкэнд, некоторые ключевые слова, такие как:

Python, Golang, C, серверная часть

У меня нет абсолютно никакого опыта работы с Objective-C или Swift, и я даже не понимаю, как связаны приложение macOS и исполняемый файл UNIX. Но все равно стоит попробовать.

Упаковка

Apache Superset — это проект Python + React, и, чтобы избежать введения нового стека, я думаю, что использование Python для разработки части пользовательского интерфейса может быть простым. Что касается серверной части, каждый, кто использует Python, знает, что упаковка — это действительно сложная проблема. Особенно с пакетами Python, включая динамически подключаемые общие библиотеки (*.dylib или *.so).

Некоторые люди могут сказать, как насчет использования «заморозки пипсов» для создания «requirement.txt» и установки их при первом запуске. Ну, в основном могут быть 2 проблемы:

1. Это нарушит соглашение «Перетаскивание в корзину означает удаление».

1. Пользовательская среда Python также может быть загрязнена и вызывать различные проблемы.

Погуглив, я обнаружил, что для создания упаковки я могу использовать в основном 3 инструмента:

1. PyInstaller (9,2 тыс. звезд, Windows/Linux/macOS)

1. cx_Freeze (905 звезд, Windows/Linux/macOS)

1. Py2app (189 звезд, только macOS, но активно развивается)

PyInstaller — довольно старый проект, с его помощью создано множество программ для Windows на основе Python, не говоря уже о том, что он имеет 9,2 тысячи звезд. Как правило, самый популярный инструмент — лучший выбор, но не в этот раз.

Насколько я знаю, не существует панацеи для решения этих проблем с упаковкой *.dylib. Большинство инструментов упаковки должны хранить кучу рецептов для решения сложных библиотек. Superset представляет множество драйверов баз данных, с которыми трудно иметь дело. Имея многолетний опыт решения проблем с *.so, мне нужен относительно простой инструмент на случай взлома. Поэтому я решил попробовать py2app.

Динамические библиотеки

Я страдал от проблем с динамическим происхождением Linux. ABI ядра Linux довольно стабилен, и Glibc очень осторожно обращается с ABI.

Даже такие библиотеки, как OpenSSL, старались изо всех сил поддерживать стабильный ABI.

Но библиотеки верхнего уровня, поставляемые с различными дистрибутивами Linux и системами управления pkg, построили матрицу.

Когда дело доходит до macOS, большинство библиотек, поставляемых с системой, довольно стабильны, а в Linux такие вещи, как libc, libc++, libpthread, libm, объединены в libSystem.B.dylib.

Хотя команда «ps» в macOS не является версией GNU, вы все равно можете увидеть большую разницу зависимых библиотек «/bin/ps» между CentOS 8.1 и macOS 12.3.

Решение упаковки динамических библиотек довольно неприятно. Но я думаю, что основных принципов всего два:

1. Держите необходимую библиотеку в самой низкой версии

1. Обрезать библиотеку до минимума с верхнего уровня

Первый принцип легко понять: более низкая версия библиотеки обычно означает меньшее количество API. Но, насколько я знаю, macOS не предоставляет для этого никакого способа кросс-компиляции. Все, что мне нужно сделать, это скомпилировать SuperChart на более ранней версии macOS. Для этого я принес подержанный Mac Mini, выпущенный в 2009 году, и установил macOS 10.15 с [macOS Catalina Patcher] (http://dosdude1.com/catalina/).

Что касается части «Trim lib», вот пример того, как я пытался решить дерево зависимостей pyarrow. Чтобы загрузить SuperChart в MAS (Mac App Store), мне нужно избавиться от зависимости Security.framework, которую вводит pyarrow.

Сначала я попытался удалить pyarrow из SuperChart. Позже я обнаружил, что это может стоить дорого, потому что оно участвует не только в части чтения паркета, но и в части сериализации супермножества. Немного покопавшись, я понял, что «Security.framework» похоже на какой-то OpenSSL системного уровня в macOS. Поскольку мы обычно используем pyarrow для сериализации/десериализации или чтения паркета, я не думаю, что криптографический материал на самом деле не нужен для pyarrow.

Легко понять, что pyarrow — это просто привязка Python к Apache Arrow. Так что все, что мне нужно сделать, это вырезать libArrow из Security.framework. Благодаря хорошо реализованной системе компиляции Arrow после установки некоторых флагов. Я получил очень чистый файл libarrow.500.dylib.

Внешний интерфейс

Для внешнего интерфейса есть 2 варианта выбора:

1. Фреймворки с графическим интерфейсом: PyQT, Tkinter, wxPython, Kivy, PySide (много старых и новых фреймворков)…

1. Веб-фреймворки: Electron

Вот несколько полезных сравнений или списков для «Python GUI Framework».

• [Сравнение Tkinter/PyQT/PySide/Kivy с Helloworld] (https://blog.logrocket.com/comparing-top-python-gui-frameworks/)

• Некоторый старый, но «официальный» список

• [Еще один «Потрясающий XXX», но со 128 тысячами звезд] (https://github.com/vinta/awesome-python#gui-development)

Кажется, есть гораздо больше вариантов, которые могут вызвать путаницу. Поэтому мне приходится сортировать свои конкретные потребности, а не просто искать в Google «Python GUI Framework» и выбирать наиболее популярный. Вот мои потребности:

1. Superset — действительно большой проект, я не хочу переписывать весь React-материал.

1. Я просто хочу приложение для macOS, а не для Linux, Windows или любой другой мобильной платформы.

1. Чем меньше, тем лучше

Electron.js действительно очень популярен после того, как просто:

ps вспомогательный | grep '(Renderer).app' | grep -v "Google Chrome.приложение"

Я наткнулся на 3 приложения, созданных с помощью Electron.js, которые в настоящее время работают на моем MacBook.

Но, насколько я знаю, почти каждая ОС поставляется с XXWebView внутри, чтобы приложение могло легко открывать веб-страницу. Почему бы мне просто не использовать это вместо упаковки Chromium, которая делает мой пакет примерно на 100 МБ больше?

Итак, я получил pywebview, который позволил мне открыть и управлять WKWebview для эмуляции пользовательского интерфейса приложения. А также, благодаря моему выбору "чем меньше, тем лучше" появилась возможность поставить SuperChart на MAS . Поскольку Chromium использует некоторые устаревшие API macOS, которые не разрешены для MAS.

Возможно, заголовок может быть таким: «Как я разместил приложение на основе Python в Mac App Store».

SuperChart в MAS

Также опубликовано [здесь] (https://medium.com/@auxten/how-i-made-apache-superset-a-macos-app-ba7166f8b140)