import { PythonRuntime } from '../base.ts';
import { EVALUATOR, type Evaluator } from '../../mixin.ts';
import type { EvalResult, EvalValue, RunArgs, RunResult, RuntimeOptions } from '../../types.ts';
import type { MountResolver } from '../../resolver.ts';
import type { BridgeDispatchFn } from '../../types.ts';
/**
 * Run Python code on the Monty sandboxed interpreter (`@pydantic/monty`).
 *
 * Code executes in a crash-isolated Monty worker: no host filesystem,
 * environment, or network access. `pathlib` I/O is serviced through the
 * workspace bridge, so the code sees the workspace mounts and nothing
 * else, and the run's env is readable both ways python's monty spells
 * it: `os.getenv` and `os.environ` (a dict copy, so the two hosts run
 * the same program). Command-line arguments are exposed as the
 * `argv` global (`argv[0]` is the script name) and piped input as the
 * `stdin` global (bytes, None when nothing was piped). The builtin
 * `open()` is bridged (@pydantic/monty 0.0.21 carries a
 * `MontyFileHandle` back from the `os` callback), and a path under no
 * mount lives in a per-run in-memory scratch tree, exactly like
 * python's binding-side tree — so `/tmp` is real scratch space on both
 * hosts. Monty implements a Python subset; host-only features
 * (`sys.stdin`, `sys.argv`, third-party imports) are unavailable, and
 * `Path.stat()` stays unbridged until the JS binding grows a
 * StatResult marker (see MirageOSAccess) — use the pyodide runtime
 * when a guest needs stat.
 */
export declare class MontyRuntime extends PythonRuntime implements Evaluator {
    readonly name = "monty";
    readonly reach = "vfs";
    readonly runsModules = false;
    readonly [EVALUATOR]: true;
    private workspaceBridge;
    private vfs;
    private module;
    private pool;
    private poolPromise;
    private readonly evalSessions;
    constructor(options?: RuntimeOptions);
    attach(dispatch: BridgeDispatchFn, resolver: MountResolver): void;
    /**
     * Run one program, reporting any switch this engine cannot honor.
     *
     * Monty implements a Python subset with no `compile`, no `warnings`
     * and no `sys.path`, so the interpreter-init switches have nothing to
     * act on here even though every real-CPython engine honors them. The
     * notice rides on stderr and the program's own exit code stands.
     *
     * Args:
     *   args: the execution request.
     */
    run(args: RunArgs): Promise<RunResult>;
    private runOne;
    private installInterruption;
    /**
     * Evaluate code in-process; the last expression is the value.
     *
     * One-shot mode evaluates on a throwaway pool session; a session id
     * keeps the session (heap and namespace) alive per id, which is the
     * console. Inputs bind as globals via monty's native mechanism, and
     * the code sees workspace files through the same bridge agent code
     * uses. Console failures come back as transcript results (stderr +
     * exitCode 1); one-shot failures reject with EvalError.
     */
    eval(code: string, opts?: {
        inputs?: Record<string, EvalValue>;
        session?: string;
    }): Promise<EvalResult>;
    close(): Promise<void>;
    /**
     * The mount view for one command, with its negative cache cleared.
     *
     * python builds a fresh `MirageOSAccess` per run, so its absence
     * cache never outlives a command; this view is attached once, so it
     * has to be told. Without the reset a path a shell command created
     * between two monty commands would stay invisible to the second.
     */
    private perRunVfs;
    private ensurePool;
    private loadPool;
    private loadModule;
    private feedOne;
}
//# sourceMappingURL=runtime.d.ts.map