Sequential 'dev-link A' then 'dev-link B' previously left A/bin in
PATH because the prepend didn't strip the old one. unlink had the
same issue (it was trying to strip $(dirname $0), which only worked
if you invoked unlink via an absolute path that happened to match
the dev-link bin).
Both now read the previous OMARCHY_PATH from /etc/omarchy.conf before
overwriting/deleting it, and strip that path's bin/ from PATH before
prepending the new one (or nothing, for unlink).
A pass over the install scripts, dev-tools commands, and Hyprland Lua
files that I had stuffed with explain-everything preambles. Most of
those rationales (which files ship where, why hyprctl setenv doesn't
suffice, etc.) belong in commit messages or PR descriptions, not in
code people have to read forever. Kept the few comments that document
genuinely non-obvious behaviour: the keybind-env reason for hl.env in
envs.lua, why the runtime PAM seds stay scripted in
increase-lockout-limit, the chroot/--now distinction in chroot.sh, and
the dev-pkg-test split-install reason.
The previous format wrote 'export OMARCHY_PATH="${OMARCHY_PATH:-<path>}"'
to /etc/omarchy.conf, intended so install.sh's script-mode OMARCHY_PATH
could win over the dev-link value. But install.sh doesn't source
/etc/omarchy.conf (only profile.d/uwsm/bash do, all post-install), so the
guard was protecting a non-scenario.
It also caused a real bug: paths.lua parses /etc/omarchy.conf as text
and returned the literal '${OMARCHY_PATH:-<path>}' string as the
omarchy_path, breaking dev-link in Hyprland.
Switch to plain 'export OMARCHY_PATH="<path>"'. dev-link is the only
writer, and when it's active, its value should win unconditionally.
When the script is run under outer sudo, the environment loses
HYPRLAND_INSTANCE_SIGNATURE, XDG_RUNTIME_DIR, and DBUS_SESSION_BUS_ADDRESS,
so the 'hyprctl version' check silently fails and the live-session
refresh (setenv / import-environment / restart shell / hyprctl reload)
gets skipped. The user is left with /etc/omarchy.conf written but no
session updates — confusing because the env in the current shell still
shows the old value.
Reject EUID=0 invocations with a clear message pointing at the right
pattern: invoke as your user, the script prompts for sudo only when it
needs to write /etc/omarchy.conf.
The four dev-tools commands that complete the developer-ergonomics
story for the package refactor:
- omarchy-dev-link <path>: writes /etc/omarchy.conf so OMARCHY_PATH
resolves to <path> in all new shells, the Hyprland session env, and
systemd --user. Updates the live session via hyprctl setenv +
systemctl --user import-environment, restarts omarchy-shell, and
reloads Hyprland so the changes are visible immediately. Affects
every tree resolved via $OMARCHY_PATH: bin/, default/, shell/,
themes/, applications/, config/.
- omarchy-dev-unlink: removes /etc/omarchy.conf and reverses the live
session updates back to /usr/share/omarchy.
- omarchy-dev-status: reports current dev-link state (configured path,
current shell, hyprland session env).
- omarchy-dev-pkg-test [pkg] [checkout]: builds and installs a package
from the checkout via OMARCHY_SRC + makepkg -si --skipchecksums.
Used for changes that land at fixed system paths (/etc/, /usr/lib/,
udev rule bodies, plymouth themes, /etc/skel) that dev-link can't
shadow. The built package's pkgver is tagged 'dev.<short-sha>[.dirty]'
so 'pacman -Q' makes its source obvious. Defaults: package
omarchy-settings, checkout ~/Work/omarchy/omarchy-installer,
PKGBUILDs read from ~/Work/omarchy/omarchy-pkgs/pkgbuilds/.
All four ship via omarchy-dev-tools (existing PKGBUILD wildcard).
Verified package build picks them up at /usr/bin/omarchy-dev-*.
Ryan Hughes