Repository navigation
feat(install): relay client from PyPI (ag2-sparrow) + launcher that actually starts it under services - #3
Merged
Conversation
…ctually starts it under services Replaces the sparse-fetch of relay files from the sutando repo with `pip install ag2-sparrow>=0.2.0` (pipx or the dedicated venv — same isolation strategy as the worker). Supersedes #2: the 6-vs-8 closure bug disappears with the fetch itself. Also fixes a functional gap in the merged installer: the launchd/systemd units launched ONLY the worker — the RELAY_CLIENT env they set was inert (the worker never spawns the relay), so tasks never arrived under the service path. install.sh now writes ~/.agent-connect/launch.sh — one code path for every start mode (launchd/systemd/nohup/by hand) that starts the relay wired to the worker's workspace via ag2-sparrow's dir-interface env trio (AGENT_CONNECT_TASK_DIR/RESULT_DIR/STATE_DIR), then execs the worker, with the same workspace-keyed pidfile hygiene run-agent.sh uses. run-agent.sh prefers the ag2-sparrow console script; an explicitly-set legacy RELAY_CLIENT file path keeps its old behavior. The dead SUTANDO_WORKSPACE export is gone from the canonical path (the old client ignored it post-sutando#1440 — the misalignment the dir interface fixes). install.test.sh: fully offline now; asserts the launcher is written with the dir-interface wiring, interpolated absolute bins, and a worker exec; guards against sparse-fetch reappearing. Verified beyond the smoke tests with an instrumented E2E: fake relay/worker bins record their env — relay receives the aligned dir trio + token/URL, worker starts, pidfile carries both pids. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Box: Track 14 connect-agent onboarding, step-4 — BYO-agent distribution via PyPI (ag2-sparrow is live: https://pypi.org/project/ag2-sparrow/0.2.0/).
What
Relay from PyPI.
install.shinstallsag2-sparrow>=0.2.0alongside the worker (pipx or the shared venv) instead of sparse-fetching relay files from the sutando repo. Supersedes fix(install): fetch the full 8-module relay closure #2 — the 6-vs-8 closure bug disappears with the fetch itself; recommend closing fix(install): fetch the full 8-module relay closure #2 when this merges.Services actually start the relay now. The merged installer's launchd/systemd units ran only the worker; their
RELAY_CLIENTenv was inert (the worker never spawns the relay), so under the service path tasks never arrived. The installer now writes~/.agent-connect/launch.sh— one code path for launchd, systemd, nohup, and by-hand — which starts the relay wired to the worker's workspace via the dir-interface trio (AGENT_CONNECT_TASK_DIR/RESULT_DIR/STATE_DIR), thenexecs the worker, with the workspace-keyed pidfile hygiene from run-agent.sh.run-agent.sh prefers the
ag2-sparrowconsole script; an explicitly-set legacyRELAY_CLIENTfile keeps its old behavior. The canonical path drops the deadSUTANDO_WORKSPACEexport (ignored by the old client since sutando#1440 — the exact misalignment the 0.2.0 dir interface fixes).Verification
install.test.sh(now fully offline): 16/16 green — syntax, arg gates, dry-run, launcher wiring (env trio + interpolated absolute bins + worker exec), sparse-fetch-regression guard.launch.shwith fake relay/worker bins that record their env — relay received the aligned dir trio + token/URL, worker started, pidfile carried both pids.pip install ag2-sparrow==0.2.0from PyPI verified separately (imports,~/.ag2-sparrowdefaults, console entrypoint).Follow-up (not this PR)
— @sutando-qingyun-001
🤖 Generated with Claude Code