Skip to content

sandbox: pooled Monty 0.0.22 runtime; apps mirror local sys.path - #1539

Open
kumare3 wants to merge 3 commits into
mainfrom
sandbox/monty-0.0.22-pool
Open

sandbox: pooled Monty 0.0.22 runtime; apps mirror local sys.path#1539
kumare3 wants to merge 3 commits into
mainfrom
sandbox/monty-0.0.22-pool

Conversation

@kumare3

@kumare3 kumare3 commented Sep 5, 2026

Copy link
Copy Markdown
Contributor

Summary

  • pydantic-monty 0.0.17 → 0.0.22. Sandboxed code now runs on a shared process-wide AsyncMonty worker pool (src/flyte/sandbox/_runtime.py) instead of in-process Monty objects. ExternalFunctionBridge drives the async feed_start / resume loop; the dummy-input workaround is gone. ORCHESTRATOR_SYNTAX_PROMPT reflects the relaxed Monty syntax subset.
  • Default sandbox image and examples install flyte[sandbox] rather than a bare pydantic-monty pin; renovate tracks monty releases at 0 days.
  • Apps mirror local sys.path. When sync_local_sys_paths is on, app_serde injects FLYTE_SYS_PATH (container and pod-template paths), matching what _with_local_sys_paths already does for tasks. The shared logic lives in flyte._utils.local_sys_paths_env. This lets an app module in a subdirectory import sibling files at serve time.
  • Codemode chat example UI/agent updates for the new runtime.

Test plan

  • pytest tests/flyte/sandbox tests/flyte/app/runtime/test_app_serde.py (251 passed)
  • ruff check / ruff format --check on touched files
  • Deploy examples/sandbox/codemode/chat_app.py remotely and confirm sibling imports resolve

🤖 Generated with Claude Code

https://claude.ai/code/session_01XrdLwao7hk7u5tSubRQRz1

kumare3 and others added 3 commits September 5, 2026 01:02
- Bump pydantic-monty 0.0.17 -> 0.0.22 and run sandboxed code on a shared
  process-wide AsyncMonty worker pool (new sandbox/_runtime.py). The
  bridge drives feed_start/resume with async snapshots.
- Update ORCHESTRATOR_SYNTAX_PROMPT for the relaxed Monty syntax subset.
- Default sandbox image and examples install flyte[sandbox] instead of a
  bare pydantic-monty pin.
- Apps: inject FLYTE_SYS_PATH when sync_local_sys_paths is on (both
  container and pod-template paths), so an app module loaded from a
  subdirectory can import sibling files at serve time. Factor the
  existing task logic into flyte._utils.local_sys_paths_env.
- Codemode chat example: UI/agent updates for the new runtime.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XrdLwao7hk7u5tSubRQRz1
Plugin lockfiles depend on the root flyte package by path, so the
pydantic-monty==0.0.22 pin in the sandbox extra has to be reflected in
each of them.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XrdLwao7hk7u5tSubRQRz1
Signed-off-by: Ketan Umare <kumare3@users.noreply.github.com>
In the full suite an earlier test leaves a global init config with
sync_local_sys_paths=True, which now injects _F_SYS_PATH into app
containers and broke three env-var count assertions. Patch
_get_init_config to None for the module; the sys-path tests opt in.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XrdLwao7hk7u5tSubRQRz1
Signed-off-by: Ketan Umare <kumare3@users.noreply.github.com>
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