From dc3360f3c77cf21ecee2c09f0dbc4dcd726cd6d5 Mon Sep 17 00:00:00 2001 From: Craig Jennings Date: Tue, 26 May 2026 20:19:16 -0500 Subject: chore: file processed eask and signal-cli handoffs to outbox --- ...from-linear-emacs-eask-provisioning-handoff.org | 70 ++++++++++++++++++++++ ...-from-.emacs.d-archsetup-signal-cli-request.org | 15 +++++ 2 files changed, 85 insertions(+) create mode 100644 assets/outbox/2026-05-23-0417-from-linear-emacs-eask-provisioning-handoff.org create mode 100644 assets/outbox/2026-05-26-1847-from-.emacs.d-archsetup-signal-cli-request.org (limited to 'assets/outbox') diff --git a/assets/outbox/2026-05-23-0417-from-linear-emacs-eask-provisioning-handoff.org b/assets/outbox/2026-05-23-0417-from-linear-emacs-eask-provisioning-handoff.org new file mode 100644 index 0000000..9fc5b41 --- /dev/null +++ b/assets/outbox/2026-05-23-0417-from-linear-emacs-eask-provisioning-handoff.org @@ -0,0 +1,70 @@ +#+TITLE: Handoff — provision Eask (@emacs-eask/cli) in archsetup +#+DATE: 2026-05-23 Sat + +* Heads-up (cross-project handoff) + +This note came out of a linear-emacs session, not an archsetup one. It landed here because the gap it describes belongs to archsetup. Process it from archsetup's next session. + +Source project: =~/code/linear-emacs=. Date discovered: 2026-05-23. + +* Eask provisioning :tooling:eask: + +Add =@emacs-eask/cli= to archsetup's provisioning, and confirm whether anything eask-related needs stowing. + +** Why + +Setting up a test harness for =linear-emacs= (Eask + Makefile + undercover coverage, modeled on chime's) surfaced that *Eask is installed by hand and isn't declared anywhere in archsetup or the dotfiles repo.* + +Evidence from the current machine: + +- =~/.local/bin/eask= is an npm symlink → =../lib/node_modules/@emacs-eask/cli/eask.js= — a plain =npm install -g @emacs-eask/cli=, not a stow symlink. +- A full-text search of =~/code/archsetup= and =~/.dotfiles= finds zero references to =eask= / =emacs-eask=. +- =~/.eask/= (eask's global package store) is a real directory, not a symlink — not stowed. + +So a fresh machine provisioned from archsetup won't have eask. Both =chime= and =linear-emacs= now depend on it: their =make setup= / =make test= / =make coverage= all shell out to =eask=, and the Makefile can detect its absence but can't install it. As more Emacs packages adopt the chime-style harness, this dependency only grows. It belongs in the declarative setup like every other dev tool. + +** What to add + +archsetup already installs the Node toolchain in the dev-tooling section (around lines 1976-1978): + +#+begin_src bash +pacman_install nodejs # Node-js JavaScript runtime environment +pacman_install npm # Node-js package manager +aur_install nvm # Node-js version manager +#+end_src + +Add an eask global-install step right after, modeled on the existing claude-code native-install block a few lines down (run as =$username=, wrapped with =display= / =error_warn=, output to =$logfile=). Something like: + +#+begin_src bash +# Eask — Emacs package build/test runner (used by chime, linear-emacs, ...) +action="installing eask via npm (global, ~/.local)" && display "task" "$action" +(sudo -u "$username" bash -c 'npm install -g --prefix "$HOME/.local" @emacs-eask/cli' >> "$logfile" 2>&1) || \ + error_warn "$action" "$?" +#+end_src + +** The npm-prefix detail (verify this) + +On the current machine =npm config get prefix= returns =/usr= (the system default, which needs root for =-g=), yet eask actually lives under =~/.local=. So eask was installed with an explicit =--prefix ~/.local= (or a per-user override at the time). The provisioning step has to pin the prefix to =~/.local= the same way, so: + +- the install runs as the user, not root; +- the =eask= binary lands at =~/.local/bin/eask= (already on =PATH=); +- it matches the layout of the other native user-space install (claude-code → =~/.local/bin=). + +Confirm whether archsetup should also set a persistent user npm prefix (=~/.npmrc= with =prefix=${HOME}/.local=, or =NPM_CONFIG_PREFIX=) so future =npm i -g= installs are user-space by default. That =~/.npmrc= *would* be a legitimate dotfile to stow — see below. + +** The "stow what it should" question + +Eask itself is effectively zero-config, so the install step is most of the story: + +- Per-project =Eask= files live in each package's own repo (already version-controlled there) — nothing global to stow. +- =~/.eask/= is a regenerable package cache, machine-specific — it should stay *un-stowed* and gitignored, not tracked. + +The one thing that *could* warrant a stow package is the npm-prefix config (=~/.npmrc=) from the section above — if archsetup sets a user-space npm prefix, that file belongs in the dotfiles repo and gets stowed in the normal stow phase. That's the natural "install package, then stow its config" flow applied to eask: the install is =npm i -g @emacs-eask/cli=; the only stowable config is the npmrc that makes user-space global installs work without root. + +Decision left to archsetup's owner: add the =~/.npmrc= stow package, or rely on the explicit =--prefix= flag in the install command alone. + +** Acceptance + +- Fresh archsetup run leaves =eask= on =PATH= at =~/.local/bin/eask=, installed as the user (no root). +- =cd ~/code/chime && make setup && make test= works on a freshly-provisioned machine. +- Decision recorded on whether =~/.npmrc= (user npm prefix) is stowed. diff --git a/assets/outbox/2026-05-26-1847-from-.emacs.d-archsetup-signal-cli-request.org b/assets/outbox/2026-05-26-1847-from-.emacs.d-archsetup-signal-cli-request.org new file mode 100644 index 0000000..ad9c903 --- /dev/null +++ b/assets/outbox/2026-05-26-1847-from-.emacs.d-archsetup-signal-cli-request.org @@ -0,0 +1,15 @@ +#+TITLE: Add signal-cli to the standard install + +Request from the .emacs.d session, 2026-05-26. + +* Ask +Add =signal-cli= (AUR) to the regular package install set, so it's present on every machine archsetup provisions rather than installed by hand per machine. + +* Why +I'm building a Signal client inside Emacs (a fork of the =signel= package) that uses =signal-cli= as its headless engine, driven over JSON-RPC. signal-cli is the runtime dependency that makes the whole feature work, and the Emacs config is the same across all my machines, so the dependency should be too. Without it in the standard install, every fresh machine is a manual =yay -S signal-cli= I'll forget. + +* Details for the recipe +- Package: =signal-cli= (AUR, not in the official repos). Installed here with =yay -S signal-cli=. +- Runtime: needs a JRE (OpenJDK 17+); already satisfied by the existing =jdk-openjdk= on these machines, but worth noting as a dependency if the install set is ever trimmed. +- Keep-current caveat: signal-cli must be updated roughly every three months or Signal-Server starts rejecting it (the client-version floor moves). So it belongs in the set that gets regular AUR updates, not pinned and forgotten. +- Linking is per-machine and interactive (scan a QR from the phone's Linked Devices), so that part stays manual. archsetup only needs to guarantee the binary is present. -- cgit v1.2.3