Metadata-Version: 2.4
Name: runtimesdk
Version: 0.2.3
Summary: Provider-agnostic runtime engine and RuntimeComputer SDK surface.
Requires-Python: >=3.11
Provides-Extra: engine
Requires-Dist: modal<2,>=1.1; extra == 'engine'
Requires-Dist: psycopg<4,>=3.2; extra == 'engine'
Requires-Dist: typer<1,>=0.12; extra == 'engine'
Description-Content-Type: text/markdown

# runtimesdk

Provider-agnostic runtime engine backed by Modal.

Install surface:

```bash
uv add runtimesdk
```

The package exposes:

- domain models for workspace specs, records, ports, exec results, and
  console-session requests/results
- RuntimeComputer contracts and enums under the same package boundary
- a `WorkspaceStore` protocol plus a PostgreSQL JSONB implementation for local
  and compatibility CLI use
- a thin Modal client/provider layer built around documented Modal lookup and
  sandbox primitives
- a `WorkspaceManager` facade for create, ensure-running, exec, console, ports,
  stop, delete, reset, and clone flows

The old `workspace-runtime` naming still exists internally as a compatibility
module, but the intended public package boundary is `runtimesdk`.

The compatibility `workspace_runtime` CLI now persists workspace records in
PostgreSQL. It reads the same database env surface as the RuntimeComputer
backend:

- `RUNTIMECOMPUTER_DATABASE_URL`, or
- `RUNTIMECOMPUTER_DATABASE_NAME` / `USER` / `PASSWORD` / `HOST` / `PORT`, with
  `PGDATABASE` / `PGUSER` / `PGPASSWORD` / `PGHOST` / `PGPORT` fallbacks

If a legacy SQLite store already exists at `.runtime/workspaces.db`, or at the
legacy `RUNTIMESDK_STORE_PATH` location, the compatibility CLI imports those
workspace records into PostgreSQL before serving the command.

`RUNTIMECOMPUTER_DATABASE_PATH` is no longer supported, and the package no
longer creates `.runtime/workspaces.db`.

`delete()` is intentionally conservative in this first cut: it removes local
state and terminates running sandboxes, but it does not attempt remote cleanup
of prior Modal volumes.
