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

Was this helpful?