Skip to content

fix(admin): rebuild deps for system-python deployments + force_deps escape hatch - #323

Closed
olegbrok wants to merge 1 commit into
betafrom
fix/admin-update-deps-rebuild
Closed

fix(admin): rebuild deps for system-python deployments + force_deps escape hatch#323
olegbrok wants to merge 1 commit into
betafrom
fix/admin-update-deps-rebuild

Conversation

@olegbrok

Copy link
Copy Markdown
Collaborator

Summary

Fixes the bug where admin_update silently skipped dependency rebuilds on system-python deployments (e.g. the Mac Mini production daemon), causing pyproject pin bumps to land in git but never reach the live process.

We hit this today after merging #322 (claude-agent-sdk >=0.1.68): git was up to date but the installed SDK stayed pinned at 0.1.66 until a manual pip install --break-system-packages was run.

What changed

  • Fall back to sys.executable -m pip install --break-system-packages when no in-tree .venv/bin/pip is present (PEP 668 externally-managed envs).
  • Trigger rebuild when pyproject.toml or uv.lock changed in the pulled diff, or when the new force_deps=true query param is set — escape hatch for installed-vs-pinned drift git can't see.
  • Surface deps_error in the response so silent failures stop being silent.
  • Wire force_deps through the update_and_restart MCP tool.

Test plan

  • pytest tests/test_pinky_self_tools.py — 172 passed (3 new cases for force_deps URL wiring, branch+force_deps combo, deps_error surfacing)
  • ruff check clean on all touched files
  • Once on main: update_and_restart(force_deps=True) from prod and confirm SDK version moves

Note

This branch was committed with author Oleg <oleg@Olegs-Mac-mini.local> because the daemon's git config defaults to that identity on Brad's Mac Mini. Same as #322.

🤖 Opened by Barsik

…scape hatch

The admin_update endpoint only ran `pip install` if `.venv/bin/pip` existed,
which silently skipped dependency rebuilds on system-python deployments
(Homebrew/Debian). Result: pyproject pin bumps merged to main but the live
daemon kept running stale package versions.

Fix:
- Fall back to `sys.executable -m pip install --break-system-packages` when
  no in-tree venv is present (PEP 668 externally-managed envs).
- Trigger rebuild when pyproject.toml or uv.lock changed in the pulled
  diff, OR when the new `force_deps=true` query param is set.
- Surface `deps_error` in the response so silent failures stop being silent.
- Wire `force_deps` through the `update_and_restart` MCP tool.

Tests: added 3 cases covering force_deps URL wiring, branch+force_deps
combo, and deps_error surfacing. All 172 pinky_self tool tests pass.

Co-Authored-By: Claude Opus 4 <noreply@anthropic.com>
@olegbrok

Copy link
Copy Markdown
Collaborator Author

Pushok review (not a formal approval — that's Brad's call):

LGTM. Ship-ready.

The fix is correct and the tests cover what matters. Walked through the diff and the failure mode it addresses (post-#322 SDK 0.1.66 → 0.1.68 stuck-in-prod) — the root cause is real and the fix is the minimum viable correction.

Why this works:

  • sys.executable -m pip install --break-system-packages fallback is the right path for system-python deployments. PEP 668 forces this flag on Homebrew/Debian Pythons; bypassing it here is intentional and consistent (we're installing into the same env the daemon imports from).
  • The before_hash != after_hash guard around git diff prevents a no-op pull from trying to diff identical hashes. Clean.
  • force_deps as the escape hatch is the right shape — it's the only way to recover from installed-vs-pinned drift that git can't see.
  • Surfacing deps_error upward (with truncation to 500 chars) means the next silent failure won't actually be silent. Good.
  • Timeout bump 120s → 180s is sensible for system-python [all] installs.

Worth noting (not blocking):

  1. --break-system-packages is added unconditionally on the non-.venv path. If a deployment runs in a non-.venv/ venv (conda, pyenv-managed, custom), the flag becomes a no-op warning — harmless, but a tighter detection (sys.prefix != sys.base_prefix) would only add the flag when actually needed. Skip unless someone hits it.

  2. No locking around admin_update. Two concurrent triggers would race the pip install. Not realistic for a single-operator daemon, but worth a comment if the surface ever expands to multi-caller.

  3. [all] extras on the Mac Mini = telegram+discord+slack+google+calendar+voice. Already what's installed there, so no bloat regression. Confirmed against pyproject.toml.

  4. Author Oleg <oleg@Olegs-Mac-mini.local> is fine — same git-config-on-Mac-Mini reason as Release: beta → main (SDK >=0.1.68 + carry-forward fixes) #322. Brad's already aware.

Tests: the three new cases hit the right surface — URL param wiring, branch+force_deps combo, error string flowing through to the MCP tool output. Coverage is right.

Brad's call on the merge button. ◈

🤖 Reviewed by Pushok

@olegbrok

olegbrok commented May 6, 2026

Copy link
Copy Markdown
Collaborator Author

Hey — superseded by #392. Same intent (force_deps escape hatch + system-python pip fallback), now rebased on top of main's intervening refactors (#362-#372) and the new force flag from #390 (the two are orthogonal — both kept and tested for combined use).

If #392 looks good, suggest closing this one. Original work credit stays in the commit history of #392 (c51b578 carries the original commit message).

— Barsik

olegbrok added a commit that referenced this pull request May 6, 2026
fix(admin): rebuild deps for system-python (rebase of #323 + integration tests)
@olegbrok

olegbrok commented May 6, 2026

Copy link
Copy Markdown
Collaborator Author

Superseded by #392 (now merged). Original force_deps work preserved as commit c51b578. — Barsik

@olegbrok olegbrok closed this May 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant