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-баги.

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

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

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

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

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

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

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

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

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

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

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

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

Но он:

  • работает,

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

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

Заключение

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

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

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

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

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

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