Scripting Reference
This page documents the public headless scripting API exposed by the studio Python package.
It focuses on these public symbols:
StudioScenarioinstall_logging_eventenable_logging_stdoutdisable_logging_stdout
If you haven't run a scenario headlessly before, read the Headless section first and then come back here for API details.
Imports
All of the APIs documented here are exported from the top-level studio package:
from studio import (
StudioScenario,
install_logging_event,
enable_logging_stdout,
disable_logging_stdout,
)Type Stubs
The public headless surface can be found here:
StudioScenario
StudioScenarioStudioScenario is the main entry point for loading and running a .pmod file without the desktop UI.
Constructor
verification_code
verification_codeThis value is used to configure licensing for headless execution.
Common patterns:
Local machine / server: pass the verification code string.
Docker / CI: mount a license file into the container and pass its path as
verification_code.
For non-interactive environments (Docker/CI/services), always pass verification_code explicitly. { % endhint %}
Typical lifecycle
In most scripts you will:
Create the scenario (
StudioScenario(...))Load a
.pmod(load_scenario(...))Run it (
run(...))Cleanup (
cleanup())
cleanup() is important in long-running processes (services, batch jobs) to release memory and reset runtime state. { % endhint %}
Loading a .pmod
.pmodReturns
StudioScenarioon success.Returns
Noneif the path does not exist.
If your scenario references external resources, keep the same directory structure used on desktop (see the βTransferring .pmod filesβ section).
Running a scenario
The runtime validates that the number of arguments matches the number of scenario inputs.
If your .pmod has:
0 inputs: call
scenario.run()orscenario.run(())1 input: call
scenario.run((value,))2 inputs: call
scenario.run((value1, value2))
args must be a tuple. For a single input, remember the trailing comma: (value,). { % endhint %}
More StudioScenario Methods
StudioScenario MethodsThis section covers additional public methods you can use for automation and debugging.
Loading without failing on missing resources
If you are moving scenarios between machines/containers and some resources may be unavailable, you can choose to load more permissively:
Load / save
Custom nodes
Load custom node Python modules from a folder:
This dynamically imports Python files. Only load trusted code. { % endhint %}
Scenario name
Ports (scenario inputs/outputs)
You can query the input/output port names:
Run a web server (optional)
If you want to expose a scenario runner over HTTP:
Events
Install lifecycle callbacks around scenario execution:
Logging Helpers
AugeLab Studio has a runtime logger used by blocks and scenarios. In headless mode you typically want one of these:
print logs to stdout while developing
forward logs into your own logging system
These helpers are global (they affect the runtime logger used by your headless scenario).
enable_logging_stdout()
enable_logging_stdout()Enables βfriendlyβ runtime logging to stdout.
Use this when you want to see block/scenario logs in the console:
disable_logging_stdout()
disable_logging_stdout()Disables runtime logging to stdout.
Useful when:
you are using
install_logging_event(...)and want to avoid duplicated logsyou want clean output (only your own
print(...)/ logger output)
install_logging_event(event: Callable[[str], None])
install_logging_event(event: Callable[[str], None])Installs a callback that receives runtime log messages.
This is the easiest way to integrate AugeLab runtime logs into your own logging framework.
StudioScenario.install_logging_hook(hook, level=0)
StudioScenario.install_logging_hook(hook, level=0)If you prefer per-scenario hook installation (with filtering by level), use:
Keep your callback fast. If you need to do heavy work (I/O, network), consider buffering messages and processing them in another thread/process. { % endhint %}
Recommended Patterns
1) Environment variable for licensing
For scripts that run in different environments (local vs CI vs Docker), passing verification_code via an environment variable keeps code portable:
2) Always cleanup with try/finally
try/finallyLast updated
Was this helpful?