118 lines
4.2 KiB
Markdown
118 lines
4.2 KiB
Markdown
|
---
|
|||
|
|
model: claude-opus-4-7[1m]
|
|||
|
|
service: claude
|
|||
|
|
timestamp: 2026-04-17T03:49:18Z
|
|||
|
|
git_ref: 9703210
|
|||
|
|
diff_cmd: git diff HEAD~1..HEAD
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
No code was produced in this turn — this is a design/planning
|
|||
|
|
exchange for subint spawner support per issue #379. Captured
|
|||
|
|
verbatim below are the two substantive AI responses, which
|
|||
|
|
together fix the phased plan (A: modularize, B: subint, C:
|
|||
|
|
harness) and the concrete Phase A file split before any
|
|||
|
|
implementation begins.
|
|||
|
|
|
|||
|
|
## Turn 1 — initial triage + gating questions
|
|||
|
|
|
|||
|
|
> Read: issue #379, current `spawn/_spawn.py` (847 lines),
|
|||
|
|
> and pyproject pins.
|
|||
|
|
>
|
|||
|
|
> ## Task summary
|
|||
|
|
> Design/plan/implement subint backend per #379, plus
|
|||
|
|
> modularize `spawn/_spawn.py` into per-backend submods, plus
|
|||
|
|
> harness flag for test parametrization.
|
|||
|
|
>
|
|||
|
|
> ## Key finding
|
|||
|
|
> `pyproject.toml:12` pins `requires-python = ">=3.12, <3.14"`
|
|||
|
|
> — but `concurrent.interpreters` / PEP 734 **only lands in
|
|||
|
|
> 3.14**. This is the load-bearing design question before
|
|||
|
|
> coding.
|
|||
|
|
>
|
|||
|
|
> ## Proposed phasing (incremental commits)
|
|||
|
|
> - **Phase A — modularize** `_spawn.py`: extract `trio_proc`
|
|||
|
|
> → `spawn/_trio.py`, `mp_proc` → `spawn/_mp.py`, keep
|
|||
|
|
> generic helpers (`hard_kill`/`soft_kill`/`new_proc`
|
|||
|
|
> dispatcher/`SpawnMethodKey`) in a slim core. Tests green
|
|||
|
|
> at each step.
|
|||
|
|
> - **Phase B — `_subint` backend**: extend `SpawnMethodKey`
|
|||
|
|
> with `'subint'`; reuse UDS transport by default; shm is
|
|||
|
|
> escape-hatch follow-up.
|
|||
|
|
> - **Phase C — harness**: add backend-parametrize flag, skip
|
|||
|
|
> subint when Python < 3.14.
|
|||
|
|
>
|
|||
|
|
> ## Gating questions before I start
|
|||
|
|
> 1. **Python pin**: bump `<3.15` and feature-gate subint
|
|||
|
|
> tests (a), require 3.14 outright (b), or backport shim
|
|||
|
|
> (c)? I'd recommend (a).
|
|||
|
|
> 2. **PR strategy**: one branch, commits per phase (current
|
|||
|
|
> `claude_bun_opus4.7_subint_spawner_backend`)? Or split
|
|||
|
|
> Phase A as its own PR first?
|
|||
|
|
> 3. **`fork()`-via-subint hack** from the issue's "Our own
|
|||
|
|
> thoughts" section — v1 or follow-up? I'd defer to
|
|||
|
|
> follow-up.
|
|||
|
|
> 4. **Prompt file line 32 is truncated** — what's the
|
|||
|
|
> existing harness flag name you had in mind ("using the
|
|||
|
|
> existing ___")?
|
|||
|
|
>
|
|||
|
|
> Which of these are already decided vs. open?
|
|||
|
|
|
|||
|
|
## User answers (for the raw record)
|
|||
|
|
|
|||
|
|
1. bump `<3.15`, feature-gate — option (a).
|
|||
|
|
2. split Phase A as its own PR first.
|
|||
|
|
3. defer `fork()`-via-subint hack.
|
|||
|
|
4. harness flag is `--spawn-backend` CLI → `start_method`
|
|||
|
|
fixture, per `tractor._testing._pytest`. Prompt file
|
|||
|
|
updated accordingly.
|
|||
|
|
|
|||
|
|
## Turn 2 — concrete Phase A plan
|
|||
|
|
|
|||
|
|
> Good — prompt file now ends cleanly; harness flag
|
|||
|
|
> confirmed as `--spawn-backend` CLI → `start_method`
|
|||
|
|
> fixture (via `_testing/pytest.py:193,355`). Also noted
|
|||
|
|
> `pytest.py:345-349` hardcodes valid backends as a string
|
|||
|
|
> tuple — `typing.get_args(SpawnMethodKey)` should drive
|
|||
|
|
> that list.
|
|||
|
|
>
|
|||
|
|
> ## Phase A — concrete plan (separate PR)
|
|||
|
|
>
|
|||
|
|
> **File split** in `tractor/spawn/`:
|
|||
|
|
> - `_spawn.py` stays as "core": keeps `SpawnMethodKey`,
|
|||
|
|
> `_spawn_method`, `proc_waiter`, `try_set_start_method`,
|
|||
|
|
> `exhaust_portal`, `cancel_on_completion`, `hard_kill`,
|
|||
|
|
> `soft_kill`, `new_proc` dispatcher, `_methods`
|
|||
|
|
> registry. Kept at this path so `_testing/pytest.py:228`
|
|||
|
|
> and other external imports don't break.
|
|||
|
|
> - `_trio.py` ← `trio_proc()` (lines 448–671, ~224 lines)
|
|||
|
|
> - `_mp.py` ← `mp_proc()` (lines 672–842, ~171 lines)
|
|||
|
|
> - `_methods` dict imports the two backend fns from the
|
|||
|
|
> new modules.
|
|||
|
|
>
|
|||
|
|
> **Commits** (each green via `/run-tests`):
|
|||
|
|
> 1. Drive `_testing/pytest.py` backend-tuple from
|
|||
|
|
> `get_args(SpawnMethodKey)` — tiny prep.
|
|||
|
|
> 2. Extract `trio_proc` → `spawn/_trio.py`; `_methods`
|
|||
|
|
> imports it.
|
|||
|
|
> 3. Extract `mp_proc` → `spawn/_mp.py`; `_methods`
|
|||
|
|
> imports it.
|
|||
|
|
> 4. Tidy `spawn/__init__.py` docstring to describe new
|
|||
|
|
> layout.
|
|||
|
|
>
|
|||
|
|
> No pyproject pin bump in Phase A (that's Phase B).
|
|||
|
|
>
|
|||
|
|
> **Workflow**: I'd run this in a new worktree via
|
|||
|
|
> `/open-wkt spawn_modularize` (branch
|
|||
|
|
> `wkt/spawn_modularize`), then open a PR before returning
|
|||
|
|
> to the current `claude_bun_opus4.7_subint_spawner_backend`
|
|||
|
|
> branch for Phase B/C.
|
|||
|
|
>
|
|||
|
|
> Green-light to `/open-wkt` and start Phase A?
|
|||
|
|
|
|||
|
|
## User final response
|
|||
|
|
|
|||
|
|
> all this first then yes, green light.
|
|||
|
|
|
|||
|
|
— log this `/prompt-io` entry first, then proceed with
|
|||
|
|
Phase A in a worktree.
|