Skip to content

[db-executable-env] Phase 1: ExecutableEnvironment + ExecutableTool skeleton#2467

Draft
aniruddh-alt wants to merge 2 commits into
aniruddh-alt/db-executable-env-trunkfrom
aniruddh-alt/db-executable-env-01-executable-skeleton
Draft

[db-executable-env] Phase 1: ExecutableEnvironment + ExecutableTool skeleton#2467
aniruddh-alt wants to merge 2 commits into
aniruddh-alt/db-executable-env-trunkfrom
aniruddh-alt/db-executable-env-01-executable-skeleton

Conversation

@aniruddh-alt

Copy link
Copy Markdown
Contributor

Description

Phase 1 of the db-executable-env phase chain, target branch: aniruddh-alt/db-executable-env-trunk.

What changed: Adds the abstract ExecutableEnvironment base class and ExecutableTool — the middle layer that future executable transports (database, HTTP, filesystem, MCP) will subclass.

Why: We need a shared executor-resolution / lifecycle layer before adding concrete transports. Mirrors Oumi's inference engine hierarchy (BaseInferenceEngine → RemoteInferenceEngine → AnthropicInferenceEngine). Replaces the monolithic PR #2441 with phase-sized units that each leave the trunk in a buildable, testable state.

Phase chain context

  • Feature trunk: aniruddh-alt/db-executable-env-trunk (will become integration PR to main once all phases land)
  • Phases merged into trunk: (none yet)
  • This phase: 1 (Executable base skeleton)
  • Next phase: 2 (Database executable skeleton) — open in parallel, branched off this phase's branch so the imports resolve; will rebase onto trunk once this PR merges.
  • Phases remaining: 3+ TBD (ExecutableEnvironment _step_one implementation, DB env engine + dialect guards, error wrapping + audit, example, postgres integration tests)

What's in this PR (244 lines)

File Purpose
src/oumi/environments/executable_environment.py Abstract base — class shape, batch step()_step_one dispatch, _build_execution_context abstract hook, _absorb_result and close default no-ops. _step_one raises NotImplementedError (skeleton).
src/oumi/environments/executable_tool.py ToolParams subclass that enforces a non-empty executor dotted path.
src/oumi/environments/__init__.py Exports ExecutableEnvironment and ExecutableTool.
tests/unit/environments/test_executable_environment.py Skeleton-shape tests: abstract instantiation rejected, class vars correct, batch dispatch reaches _step_one, defaults are no-ops.
tests/unit/environments/test_executable_tool.py Skeleton-shape tests: rejects empty executor; accepts dotted path.

Why a skeleton phase

Each phase in this chain leaves the trunk buildable. The skeleton ships the shape (subclasses can be written against the abstract surface) but raises NotImplementedError from _step_one so no caller is misled into thinking execution is wired. Implementation lands in a follow-on phase.

The batch step(calls: list[tuple[str, dict[str, Any]]]) -> list[ToolResult] signature matches BaseEnvironment.step exactly — fixing the signature mismatch flagged on PR #2441.

Related issues

(No associated issue — direct continuation of the work that lived in PR #2441.)

Before submitting

  • Did you add / update tests where needed?
  • Did you run the local test suite? pytest tests/unit/environments/ — 67/67 passing on this branch.

Abstract base for envs that run user-supplied dotted-path executors.
Subclasses provide the per-call execution context (DB conn, HTTP client,
FS root, ...) via _build_execution_context. The base owns batch step()
dispatch to _step_one, the _absorb_result post-hook, and the close
lifecycle.

This phase ships the skeleton: class shape, batch step() dispatch, and
abstract _build_execution_context hook. Concrete _step_one (executor
resolution, ToolResult validation, output_schema validation,
_absorb_result invocation) lands in a follow-on phase.

ExecutableTool is a small ToolParams subclass enforcing a non-empty
executor dotted path.

First phase of the db-executable-env trunk chain; targets the trunk
branch, will integrate to main with the rest of the feature.
@gitar-bot

gitar-bot Bot commented May 20, 2026

Copy link
Copy Markdown

Gitar is working

Gitar

Strips "skeleton phase", "arrives in a later phase", and "future
HTTPExecutableTool" framing from docstrings and NotImplementedError
messages. The PR description carries the skeleton framing; the code
should describe what the symbol is, not which PR introduced it.

Also renames test_step_one_is_skeleton to
test_step_one_raises_not_implemented to match the cleaned-up exception.
@shanghongsim

Copy link
Copy Markdown
Contributor

Limited understanding of what has been discussed for this PR design so far. Approving cautiously. Would be good if someone else more familiar with the northstar design can look it over

@aniruddh-alt

Copy link
Copy Markdown
Contributor Author

Limited understanding of what has been discussed for this PR design so far. Approving cautiously. Would be good if someone else more familiar with the northstar design can look it over

@jgreer013 😅

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.

3 participants