Let the app own its Hermes runtime

Pairing the app with the mise CLI does not work, and pinning the app back to
the tag behind PyPI's release does not rescue it: v2026.7.20's desktop reaches
"backend is ready" and then hangs without ever opening a window, against its
own matching runtime. Only the newest app against a runtime built from its own
commit starts, which is the arrangement upstream ships.

So the package returns to the newest tag and the launcher sets
HERMES_DESKTOP_IGNORE_EXISTING, which keeps the app off whatever hermes is on
PATH -- on Omarchy that is the mise CLI installed for the terminal agent, a
different release, and the version gap is what produced the 401. The app
provisions ~/.hermes itself on first launch instead.

mise and uv are no longer dependencies, since the launcher no longer installs
anything; git and curl are, because the app's own bootstrap needs them.
This commit is contained in:
Omabot
2026-08-19 06:12:11 -07:00
parent 1a394eae60
commit 9b0dd041f8
2 changed files with 21 additions and 42 deletions
+13 -13
View File
@@ -5,20 +5,20 @@
# so there is no vendor binary to repackage. Their electron-builder config does
# carry a Linux target, though, and it works; this builds it.
#
# The version tracks PyPI rather than the newest tag. The app and the Hermes
# CLI have to agree on the dashboard session-token handshake, and a newer app
# against an older CLI fails its readiness probe with a 401 and never starts.
# Upstream never hits this because their installer builds the app from the same
# checkout it installs the CLI from -- and refuses a non-editable source
# install, so the CLI cannot simply be pinned to the app's commit instead.
# v2026.7.20 is the tag behind hermes-agent 0.19.0 on PyPI; both move together.
# The app only runs against a Hermes runtime built from its own commit, so it
# provisions one itself under ~/.hermes on first launch and the package stays
# on the newest tag. Pairing it with the mise CLI instead was tried and does
# not work: PyPI trails the tags, and the version gap fails the readiness probe
# with a 401. Pinning back to the tag behind PyPI's release does not rescue it
# either -- v2026.7.20's desktop hangs after "backend is ready" without ever
# opening a window, against its own matching runtime.
#
# The app is only a shell: it runs `hermes serve` against a Hermes CLI it does
# not ship, and clones its own copy with the upstream install script when it
# finds none. /usr/bin/hermes-desktop heads that off. See hermes-desktop.sh.
pkgname=hermes-desktop
pkgver=2026.7.20
pkgver=2026.8.18
pkgrel=1
pkgdesc='Native desktop shell for Hermes Agent'
arch=('x86_64')
@@ -31,8 +31,10 @@ depends=(
'cairo'
'dbus'
'expat'
'curl'
'gcc-libs'
'gdk-pixbuf2'
'git'
'glib2'
'glibc'
'gtk3'
@@ -50,12 +52,10 @@ depends=(
'libxkbcommon'
'libxrandr'
'mesa'
'mise'
'nspr'
'nss'
'pango'
'systemd-libs'
'uv'
'xdg-utils'
)
@@ -73,15 +73,15 @@ options=('!strip' '!debug')
# before falling back to `git rev-parse`. That fallback is wrong here: makepkg
# builds inside this repository, so git ascends out of srcdir and stamps the
# app with an omarchy-pkgs commit that means nothing upstream.
_commit=3ef6bbd201263d354fd83ec55b3c306ded2eb72a
_commit=e624e9fde561e1add9388384012b295fde669ade
_srcdir="hermes-agent-${pkgver}"
source=("${pkgname}-${pkgver}.tar.gz::${url}/archive/refs/tags/v${pkgver}.tar.gz"
'hermes-desktop.sh'
'hermes-desktop.desktop'
'hermes-desktop.png')
sha256sums=('285f3fc134ff466a90065e1517801a68993733b807158ee8f32aa01613786990'
'e7c0e1fd343e9b013de4575fbefdd4f03b3b62fb5c2c2dd3c508f4a26b6608ea'
sha256sums=('1e3d39d3638ec15fa9d31af262568a953e9272090deb1c50c44cd401175f5b80'
'fc5f07c9bf77c82366ba9f631ae2c86ba657ca2a4f8712034ba03800e88fe699'
'3ef685bfcf366776b025d26c37d32854d8d4aa2023b2bd07c8e08b001ef1e8c4'
'd60d164e24fdcf6532133b8ea43c77a201e4b9e9dbc396187b58d51d8590ef52')
+8 -29
View File
@@ -1,35 +1,14 @@
#!/bin/bash
set -euo pipefail
# The desktop app is only a shell: it runs `hermes serve` against a Hermes CLI
# it does not ship. Finding none it offers to install its own, which clones an
# unpinned checkout into ~/.hermes/hermes-agent -- and that copy then wins
# forever, because the app checks ~/.hermes before it checks PATH.
#
# So guarantee the CLI here rather than relying on anything else having run.
tool='pipx:hermes-agent[extras=all]'
python='3.13'
# Hermes declares Requires-Python <3.14; left to itself uv builds the venv
# against Arch's 3.14 anyway and only fails later, inside a dependency. The
# cooldown override is exported so the version resolved to run is the one just
# installed. Both mirror omarchy-install-hermes-cli -- keep them in step.
export UV_PYTHON="$python"
export MISE_MINIMUM_RELEASE_AGE=0
if command -v omarchy-install-hermes-cli >/dev/null 2>&1; then
omarchy-install-hermes-cli --now
elif ! [[ -d "$(mise where "$tool" 2>/dev/null)/hermes-agent/lib/python$python" ]]; then
echo "Installing the Hermes CLI (this takes a minute)..." >&2
mise use -g --quiet --force "$tool" || true
fi
# Hand the app the real executable rather than leaving it to search. Its PATH
# probe allows 15 seconds, which nothing that still has installing to do can
# meet.
hermes_bin="$(mise where "$tool" 2>/dev/null)/bin"
[[ -d $hermes_bin ]] && export PATH="$hermes_bin:$PATH"
# Hermes Desktop is a shell around a Hermes runtime, and it only works against
# one built from its own commit. A CLI from PyPI is always a different release
# -- PyPI trails the tags -- and the mismatch fails the app's readiness probe
# with 401 Unauthorized. So keep it away from whatever `hermes` is on PATH,
# which on Omarchy is the mise CLI installed for the terminal agent, and let
# the app provision and manage its own runtime under ~/.hermes. That is the
# arrangement upstream ships, and the only one that starts.
export HERMES_DESKTOP_IGNORE_EXISTING=1
# Chromium's own Ozone detection falls back to XWayland often enough to matter,
# and the result is a blurry window on every scaled display. Ask for Wayland