chore: migrate from Poetry to uv

[DhairyaPatel7]

Summary

• Convert pyproject.toml to PEP 621 with [tool.uv].package = false (this repo runs scripts + tests, never publishes a wheel).
• Bring pytest + pytest-cov into the dev group so the unit-tests job no longer needs the separate poetry run pip install --upgrade pytest-cov shim.
• Drop the workflow's poetry run pip install --upgrade packaging override — uv's universal resolver already picks up packaging==26.2 (verified in uv.lock). The old --upgrade was working around Poetry's narrower selection from open-aea constraints and is no longer needed.
• python-tests.yml: replace the Install Poetry / Configure Poetry / poetry env use / poetry install / poetry run blocks across all 5 jobs (e2e-test-run-service, e2e-test-staking, changes detector, e2e-test-migrate-to-pearl, unit-tests) with astral-sh/setup-uv@v6 (pinned to 0.11.15) + uv sync --all-groups --frozen + uv run pytest.
• Update the changes-detector diff allowlist from poetry\.lock$ to uv\.lock$ so the migration job still re-triggers on any dep bump.
• Drop the "Clean Python cache" stanzas — they existed to wipe stale poetry venvs / poetry.lock before fresh installs; irrelevant under uv where uv sync --frozen is hermetic.
• Drop poetry.lock; commit uv.lock.

Verified locally

• uv lock --check
• uv sync --all-groups --frozen
• runtime deps importable: operate, web3, docker, halo, gql, dotenv, tqdm, psutil, autonomy, aea
• unit-tests: 359 passing on macOS Python 3.14. 11 pre-existing failures in tests/test_scripts/test_pearl_migration.py are unrelated to this PR — @dataclass(frozen=True) class _Unmigratable(Exception) trips contextlib's __traceback__ assignment on macOS Python 3.13+. The same workflow on Linux passes (most recent green: chore/deps-bump-starlette on 2026-05-18 across the same 3.10–3.14 matrix).

Note on lockstep

• olas-operate-middleware==0.15.21 matches the pin already on origin/main (commit 29b7e59), so this PR introduces no drift. Any future middleware bump will need a coordinated bump here.

Test plan

• setup discovers agent configs
• e2e-test-run-service matrix passes
• e2e-test-staking passes
• changes correctly skips/triggers e2e-test-migrate-to-pearl on this PR (touches uv.lock + .github/workflows/python-tests.yml, so it should run)
• e2e-test-migrate-to-pearl passes
• unit-tests matrix passes on 3.10 → 3.14 (Linux)

[DIvyaNautiyal07]

Ripple sweep — concept-changed-but-not-everywhere

The main README.md is updated, but the migration left stale Poetry references in sub-trees and in a sibling test file's rationale. After this merges, a developer following these docs hits the same poetry: command not found the main script now avoids.

Sub-directory READMEs (P1):

• scripts/optimus/README.md lines 18-19 — poetry install, poetry run python -m scripts.optimus.migrate_legacy_optimus ...
• scripts/predict_trader/README.md lines 16, 22, 28, 197-198 — multiple poetry run / poetry install

Stale rationale in tests/test_migrate_to_pearl.py (P1):

• Line 95: the _copy_repo_to docstring still says symlinking .venv avoids "a fresh poetry install in dest [that] triggers PEP 517 sdist rebuilds (halo, python-baseconv) that fail under Poetry 2.4 + setuptools >= 80." Under uv, the symptom may be different (or absent). The rationale should be re-justified or rewritten in uv terms — the new symlink fix in test_run_service.py cites a different reason (stale pyvenv.cfg), and the two docstrings now disagree.
• Lines 342-343: comment says "We drop VIRTUAL_ENV so poetry inside the spawned shell creates / uses its own env" — should be "so uv inside the spawned shell...".

[OjusWiZard]

Additional findings from a multi-agent review pass over the diff at 870a0ba. Most-load-bearing items are the two unchecked _wait_for_containers_stopped returns (HIGH) and the unquoted $@ across the user-facing scripts (MEDIUM). The blocking dep-bump finding from @LOCKhart07 and the stale-Poetry sweep from @DIvyaNautiyal07 are not duplicated here.

Two additional observations on lines outside this PR's diff (so left here rather than inline):

• tests/test_run_service.py:836 — cls.temp_env.pop('POETRY_ACTIVE', None) is now dead, but UV_PROJECT_ENVIRONMENT (and UV_VENV) are not popped. A contributor running tests inside a uv run shell will have those vars leak into the pexpect-spawned subprocesses, causing uv run inside them to target the outer project's venv instead of the tempdir-symlinked one — silently defeating the symlink isolation added at line 1050.
• tests/test_run_service.py:1107–1116 — TestAgentService.teardown_class is a verbatim copy of TempDirMixin.teardown_class (lines 1075–1084); since it inherits from TempDirMixin the override adds nothing and can be deleted. Independently, the inner try/except Exception: in the parent calls cleanup_directory(...) with identical args in both branches — the try/except is a no-op.

[LOCKhart07]

Review — uv migration

Most prior-round issues are genuinely resolved (verified below). One blocking item remains in the latest commit (8eb24c8).

---

🔴 Blocking — the teardown_class "raise on timeout" fix (3266762896) is non-functional

tests/test_run_service.py:874. The new raise RuntimeError(...) on poll timeout is lexically inside the inner try: (line 863), whose broad except Exception as e: at line 888 catches it (RuntimeError ⊂ Exception) and downgrades it to a single logger.error(...). Traced control flow:

• The exception never propagates out of teardown_class → pytest sees teardown return normally → the test class does not fail. This contradicts the resolution reply on 3266762896 ("the test class fails decisively").
• Because the raise is at line 874, before the force-stop fallback at lines 879–887 (client.containers.list(...) → container.stop()/remove()), that cleanup is skipped on the timeout path. Straggler containers are neither force-removed nor surfaced — only a log line. This is the exact "containers leak into the next CI job" scenario the comment was meant to prevent, and a regression vs. the pre-8eb24c8 flat-sleep behavior (which always fell through to force-stop).

Fix: keep the force-stop loop running on timeout, and make the failure decisive outside the swallowing except — e.g. set a flag in the inner block, then raise after line 891 (outside the inner try), so cleanup still runs and the timeout actually fails the class.

🟡 Non-blocking — same root cause in ensure_service_stopped

tests/test_run_service.py:487-488. if not _wait_for_containers_stopped(...): return False returns before the force-stop fallback at lines 491–500. On main the flat sleep always fell through to force-stop+remove leftovers; now on timeout they're left running and leak into the next parametrized config / CI job. The caller does raise on False (good signal), but the cleanup backstop is lost. Suggest force-stopping remaining containers before returning False.

🟡 Non-blocking — PR description "Note on lockstep" is stale

It says olas-operate-middleware==0.15.21 is "currently in flight via the middleware PR valory-xyz#442". It's already pinned on origin/main (commit 29b7e59). Reword or drop so it doesn't imply an unmerged dependency.

---

Verified resolved (no action needed)

• 3266447547 (LOCKhart07, "blocking" dep upgrades) is invalid — confirmed pyproject.toml deps are byte-for-byte identical to current origin/main (617f813); it was compared against a stale main snapshot. DhairyaPatel7's rebuttal is correct.
• "$@" quoting fixed across all 9 shell scripts; all use command -v uv.
• Matrix --python ${{ matrix.python-version }} applied to both uv sync and uv run.
• Dev pins exact (pytest==9.0.3, pytest-cov==7.1.0); uv.lock consistent (requires-python >=3.10,<3.15, virtual workspace member, all versions match pyproject.toml).
• setup_class POSIX-guard reorder is safe — pytest does not invoke teardown_class when setup_class raises Skipped, so no AttributeError on the unset self.temp_dir.

[DhairyaPatel7]

@LOCKhart07 — thank you, the swallowed-RuntimeError catch is spot-on. Addressed all three in 07c33fa:

🔴 Blocking — teardown_class raise was swallowed. Restructured so the timeout is tracked via a poll_timed_out flag inside the inner try, the force-stop fallback at the old lines 879–887 (client.containers.list(...) → container.stop()/remove()) runs regardless of the poll outcome, and the raise RuntimeError(...) happens outside both swallowing except Exception blocks so it actually propagates to pytest. The flat-sleep cleanup behavior is preserved and the timeout now decisively fails the class instead of becoming a log line.

🟡 Non-blocking — same root cause in ensure_service_stopped. Same fix shape applied at line 487 — return False no longer short-circuits the force-stop loop at 491–500. Set poll_timed_out, run the loop, then return not poll_timed_out so the caller (which already raises on False) keeps the failure signal but the cleanup backstop runs first.

🟡 Non-blocking — PR description stale "in flight via valory-xyz#442". Reworded: olas-operate-middleware==0.15.21 is now described as "matches the pin already on origin/main (commit 29b7e59), so this PR introduces no drift," which is what's actually true. Dropped the implication of an unmerged dependency.

Diff for the teardown rework: 07c33fa

[LOCKhart07]

Verified 07c33fa — all three items from the prior review are properly resolved:

• Blocking (teardown_class): the raise RuntimeError(...) is now at method-body indentation, outside both swallowing except Exception blocks, so a poll timeout propagates to pytest and the class fails decisively. The force-stop fallback (containers.list → stop()/remove()) runs regardless of poll outcome, so the cleanup backstop is preserved.
• ensure_service_stopped: same shape — force-stop loop runs, then return not poll_timed_out; caller still raises on False but cleanup runs first.
• PR description: the lockstep note no longer implies an unmerged dependency.

Earlier-round issues remain resolved (deps byte-identical to origin/main, "$@" quoting across all 9 scripts, matrix --python pinning, exact dev pins, consistent uv.lock). No outstanding blocking concerns. LGTM.