Python environment

Scenarios run on DataMaker-hosted Python workers. You don’t manage the environment, just the script.

Runtime

Python 3.12 (current stable).
One process per scenario run. Cold start ~600 ms; warm starts effectively instant if you re-run within ~5 minutes.
Each run gets its own working directory, mounted at /workspace. Files survive the duration of the run only. For persistence across runs, see Workspace files.

Pre-installed packages

Every worker comes with these:

Package	Why
`datamaker`	The official DataMaker SDK (entrypoint of every script).
`requests`	Generic HTTP. Use this for non-DataMaker REST calls.
`httpx`	Async HTTP. Available if you’d rather use async/await.
`psycopg[binary]`	Postgres driver, if you want to run raw SQL yourself.
`pymysql`	MySQL driver.
`pymongo`	MongoDB driver.
`pandas`	DataFrame manipulation. Useful for transforming generated rows.
`pyyaml`	YAML parsing.
`python-dateutil`	Date parsing/arithmetic.
`faker`	Python’s Faker. Most cases use `dm.generate()` instead, but Faker is there if you need a quick one-off.
`pyodata`	OData client, for talking to SAP OData services directly.

Adding packages

Each scenario can declare its own requirements:

# top of your scenario:
# requirements: arrow~=1.3, polars~=0.20
import arrow, polars as pl

# normal scenario code follows

DataMaker reads the # requirements: comment, resolves the dependency tree against PyPI, and installs into the worker’s .venv before running. Subsequent runs reuse the cached install.

Pinning rules: we accept any PEP 440 version specifier (==1.2.3, ~=1.3, >=2,<3). For reproducibility, prefer ~= (compatible release).

Environment variables

Scenarios have access to:

DataMaker context: DATAMAKER_PROJECT_ID, DATAMAKER_TEAM_ID, DATAMAKER_SCENARIO_ID, DATAMAKER_API_KEY, DATAMAKER_API_URL are set automatically; the SDK reads them, so you usually don’t touch them directly.
Workspace dirs: inputs are synced into DATAMAKER_WORKSPACE_UPLOADS; write outputs to DATAMAKER_WORKSPACE_OUTPUTS (persisted after the run).
Secrets & run parameters: anything under Settings → Workspace secrets, plus the run-time parameters from the trigger, arrive as environment variables. Read with os.environ.

import os
slack_token = os.environ["SLACK_BOT_TOKEN"]            # workspace secret
env = os.environ.get("ENVIRONMENT", "dev")             # run-time parameter

What’s not there

To keep workers fast and isolated:

No shell. No subprocess.run() of arbitrary binaries (we block it at runtime).
No persistent filesystem outside /workspace.
No outbound network to private IPs unless you’ve configured a VPN connector (Enterprise plans).

Running locally

You can develop scenarios against your local Python:

pip install "git+https://github.com/automators-com/datamaker-py.git"
export DATAMAKER_API_KEY=your_api_key
python my_scenario.py

The same SDK works locally and in the worker. The only differences:

Run parameters and the workspace dirs aren’t injected; set the env vars yourself.
Workspace files aren’t mounted; fetch them with dm.get_scenario_files() / dm.download_scenario_file(...) if you need them locally.

For more, see API & SDKs → Python SDK.