For the complete documentation index, see llms.txt. This page is also available as Markdown.

Scripting Reference

This page documents the public headless scripting API exposed by the studio Python package.

It focuses on these public symbols:

  • StudioScenario

  • install_logging_event

  • enable_logging_stdout

  • disable_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

StudioScenario is the main entry point for loading and running a .pmod file without the desktop UI.

Constructor

verification_code

This 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:

  1. Create the scenario (StudioScenario(...))

  2. Load a .pmod (load_scenario(...))

  3. Run it (run(...))

  4. Cleanup (cleanup())

cleanup() is important in long-running processes (services, batch jobs) to release memory and reset runtime state. { % endhint %}


Loading a .pmod

  • Returns StudioScenario on success.

  • Returns None if 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() or scenario.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

This 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()

Enables “friendly” runtime logging to stdout.

Use this when you want to see block/scenario logs in the console:


disable_logging_stdout()

Disables runtime logging to stdout.

Useful when:

  • you are using install_logging_event(...) and want to avoid duplicated logs

  • you want clean output (only your own print(...) / logger output)


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)

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 %}


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

Last updated