Как я сделал рабочий pgAdmin4 Desktop для Arch Linux и почему это оказалось сложнее, чем кажется

pgAdmin 4 - де-факто стандартный GUI-клиент для PostgreSQL.
Он активно развивается, официально поддерживается на Debian и… при этом на Arch Linux с Desktop-версией всё стабильно плохо.

На момент написания статьи в AUR есть несколько пакетов pgAdmin4 Desktop, но ни один из них:

• не собирается стабильно,

• не переживает обновления Python / Electron,

• или требует ручных правок после установки.

В этой статье я хочу расс��азать:

• почему pgAdmin4 Desktop так плохо ложится на Arch,

• какие решения обычно ломаются,

• и какой компромиссный, но рабочий вариант в итоге получился у меня.

Немного контекста: почему pgAdmin4 Desktop - проблема

Архитектурно pgAdmin4 Desktop - это:

• backend на Python (Flask + остальные зависимости),

• frontend на JavaScript,

• desktop-обвязка на Electron,

• и жёсткое предположение upstream, что всё это запускается из virtualenv.

Для дистрибутивов Debian based это не проблема:
там спокойно живут venv внутри /usr/lib.

Но из за того что разрабы на Arch Linux положили большой и длинный... Это сразу конфликтует с "философией":

• system Python - один,

• пакеты должны быть воспроизводимы,

• runtime-загрузки и auto-updaters не приветствуются.

Почему существующие AUR-пакеты нестабильны

Если коротко, основные причины такие.

1. Жёсткая привязка к venv

Upstream pgAdmin ожидает путь вида:
venv/bin/python3

Любая попытка «подменить» это без патчей приводит к:

• падениям,

• сломанному PYTHONPATH,

• несовместимости после обновлений Python.

2. Встроенный Electron

Многие пакеты:

• либо тянут свой Electron,

• либо не переживают обновление system Electron.

3. Runtime-загрузки

Некоторые сборки:

• скачивают зависимости при первом запуске,

• или делают это через yarn/npm.

Это ломает воспроизводимость и доверие к пакету.

Цель, которую я себе поставил

Я хотел получить пакет, который:

• собирается из upstream source

• использует system Electron

• использует system Python в runtime

• не качает ничего при запуске

• воспроизводимо собирается в clean chroot

• не требует ручных правок после установки

При этом я сознательно допускал компромиссы, если они упрощают жизнь пользователю. Ну или по простому, я наставил костылей, спасибо что хотя бы рабочих.

Ключевое решение: venv только на этапе сборки

Самое важное архитектурное решение:

virtualenv используется только при сборке,
а в runtime — обычный /usr/bin/python3.

Как это реализовано:

1. Во время build():

   • создаётся временный venv,

   • туда устанавливаются все Python-зависимости pgAdmin.

2. В package():

   • содержимое site-packages копируется в /opt/pgadmin4-native/python-packages,

   • сам venv в пакет не попадает.

3. В runtime:

   • PYTHONPATH указывает на этот каталог,

   • Python системный.

Таким образом:

• зависимости изолированы,

• system Python не загрязняется,

• pgAdmin видит именно те библиотеки, которые ему нужны.

Почему /opt, а не /usr

pgAdmin Desktop — это:

• Electron-приложение,

• с собственным layout,

• со своей логикой запуска.

Размещение в /opt/pgadmin4-native позволяет:

• не смешивать файлы с системой,

• не имитировать структуру обычного Python-пакета,

• честно признать, что это application bundle.

Патчи upstream-кода

К сожалению, без патчей не обойтись.

В процессе сборки:

• жёсткие пути вида /venv/bin/python3 заменяются на /usr/bin/python3,

• относительные пути до pgAdmin4.py заменяются на абсолютные.

Это делается простыми sed патчами на этапе build
и хорошо воспроизводимо в clean chroot.

Electron

В пакете:

• нет встроенного Electron,

• используется electron34 из репозиториев Arch.

Если в будущем версия Electron изменится — это будет видно сразу,
а не через "тихие" runtime-баги.

Что в итоге получилось?

Итоговый пакет:

• pgadmin4-desktop-native

• AUR: https://aur.archlinux.org/packages/pgadmin4-desktop-native ^[1]

• GitHub: https://github.com/IlyaP358/pgadmin4-desktop-native ^[2]

На текущий момент он:

• протестирован на vanilla Arch и CachyOS,

• собирается в clean chroot,

• запускается без runtime-загрузок,

• переживает обновления Python и Electron (в пределах совместимости upstream).

Про «идеологическую чистоту»

Да, этот пакет:

• не использует system site-packages,

• не использует runtime virtualenv,

• и не вписывается идеально в абстрактную модель.

Но он:

• работает,

• воспроизводим,

• и хотя бы решает проблему пользователей.

Заключение

pgAdmin4 Desktop на Arch Linux - это пример того,
как upstream-архитектура и философия дистрибутива могут конфликтовать.

Иногда, чтобы получить стабильный результат, приходится:

• принимать компромиссы,

• ставить костыли

• и брать ответственность за то что наворотил.

Если этот пакет окажется полезным, я буду очень рад.
Если у вас есть идеи, как сделать его лучше без потери стабильности я всегда открыт для pull requests =] и обсуждение приветствуются.