Offline Fixture Workflow

Run the complete login → init → generate flow without a live server using a local fixture JSON file.

All three optixlog commands run fully offline when you supply a fixture — a local JSON file that replaces the backend. This is the recommended approach for:

Local development without server access.
Unit and integration tests in your project.
CI pipelines that should not depend on network connectivity.

The fixture file has the same shape as the live server's v0.codegen.schema response. The SDK ships with a sample fixture at tests/fixtures/schema.sample.json in the python-sdk-spec/ tree.

The --fixture flag

Pass --fixture <path> to any command to activate the offline backend:

optixlog login    --fixture tests/fixtures/schema.sample.json --api-key sk-opt-test --base-url http://x
optixlog init     --fixture tests/fixtures/schema.sample.json --all --output optixlog_gen.py
optixlog generate --fixture tests/fixtures/schema.sample.json

The --fixture flag takes precedence over the OPTIXLOG_FIXTURE environment variable.

The OPTIXLOG_FIXTURE variable

Export OPTIXLOG_FIXTURE once to avoid repeating --fixture on every command:

export OPTIXLOG_FIXTURE=tests/fixtures/schema.sample.json
optixlog login --api-key sk-opt-test --base-url http://x
optixlog init  --all --output optixlog_gen.py --no-input
optixlog generate

Full step-by-step walkthrough

Export the fixture path

Set the environment variable so every subsequent command uses the fixture automatically:

export OPTIXLOG_FIXTURE=tests/fixtures/schema.sample.json

You can also use OPTIXLOG_CONFIG_HOME to avoid writing to your real ~/.optixlog/ directory during testing:

export OPTIXLOG_CONFIG_HOME=/tmp/test-optixlog-home

Authenticate (offline)

The --api-key and --base-url values are arbitrary when using a fixture — the fixture backend ignores credentials and reads identity from the fixture file itself. Use --no-input to skip prompts:

optixlog login \
  --api-key sk-opt-test \
  --base-url http://x \
  --no-input

Expected output:

Logged in as unknown identity (unknown key). Saved globally to /tmp/test-optixlog-home/credentials.toml [profile: default] — works from any directory.

If the fixture includes an identity block, the user_email and organization_id from that block are stored instead.

Initialize (offline)

Select projects from the fixture and write optixlog.toml:

optixlog init --all --output optixlog_gen.py --no-input

Expected output:

Wrote ./optixlog.toml with 2 project(s): Grating Coupler Lab, Modulator Program.

The written optixlog.toml looks like:

[optixlog]
api_base_url = "http://x"
schema_version = 1

[codegen]
output_path = "optixlog_gen.py"
module_style = "single_file"

[[projects]]
id = "proj_grating_7f3a"
name = "Grating Coupler Lab"

[[projects]]
id = "proj_modulator_22b1"
name = "Modulator Program"

Generate typed bindings (offline)

Fetch schemas from the fixture and write the module:

optixlog generate

Expected output:

Generated ./optixlog_gen.py for 2 project(s).

The file is byte-deterministic — every run with the same fixture produces identical output.

Use the generated module

Import from optixlog_gen in your code or tests:

from optixlog_gen import OptixClient, Projects, SimulationNode

client = OptixClient(base_url="http://x", api_key="sk-opt-test")
result = client.project(Projects.GRATING_COUPLER_LAB).ingest(
    data=SimulationNode(config={}, solver="fdtd"),
    prompt="Simulated a grating coupler.",
)

Check for drift (optional)

Use --check to verify that the committed optixlog_gen.py matches the current fixture — without writing any files:

optixlog generate --check

If the file is current:

./optixlog_gen.py is up to date.

If the file is stale (exits 1):

./optixlog_gen.py is out of date; re-run `optixlog generate`.

Compact one-liner (for scripts)

OPTIXLOG_FIXTURE=tests/fixtures/schema.sample.json \
  OPTIXLOG_CONFIG_HOME=/tmp/test-optixlog-home \
  bash -c '
    optixlog login --api-key sk-opt-test --base-url http://x --no-input
    optixlog init  --all --output optixlog_gen.py --no-input
    optixlog generate
  '

Fixture backend behavior

Operation	What the fixture backend does
`whoami()`	Returns the identity from the fixture's `identity` field, or `WhoAmI("unknown", None, None, ())` if absent.
`list_accessible_projects()`	Returns all projects from the fixture's `projects` field.
`fetch_schemas(ids)`	Filters the fixture to the requested project ids. Raises `OptixLogError` for any id not found.
`close()`	No-op.

--fixture takes precedence over OPTIXLOG_FIXTURE

When both are set, the --fixture flag wins. The environment variable is a convenience for scripting; the flag is for one-off overrides.

Offline Fixture Workflow

On this page