pysepal.solara.runtime_context.resolve_scope_id#

pysepal.solara.runtime_context.resolve_scope_id()[source]#

Return the current per-connection runtime’s scope id.

Thin adapter over Solara’s own solara.scope.get_kernel_id resolver: it returns the Solara-server virtual-kernel id and otherwise falls back to the active IPython/ipykernel – covering solara run, Voila (including preheated kernels, which start before SERVER_SOFTWARE is set), and plain Jupyter Notebook/Lab. We deliberately do not reimplement that resolution; we only translate its failure modes into a typed error.

Those failure modes are every way an unusual host can shape a kernel, and all five are reachable – the ipython fallback ends in re.search(regex, kernel.config["IPKernelApp"]["connection_file"]).group(1):

  • RuntimeError – no kernel at all;

  • AttributeError – a connection filename the regex cannot parse, so re.search returns None;

  • TypeError – no connection_file key, which a traitlets Config auto-vivifies into a LazyConfigValue rather than raising;

  • KeyError – the same absence in a mapping that does not auto-vivify;

  • ImportError – solara imports solara.server.kernel_context and IPython inside the call, and pysepal declares neither.

An ImportError from the symbol itself being gone cannot reach here: the module-level check above turns that into a startup failure, so a solara API change never masquerades as a runtime that has no kernel.

Deliberately not Exception: this resolver is total about runtime shape, which is not a licence to hide bugs behind a fallback scope.

Returns:

The runtime’s scope id.

Raises:

UnsupportedSolaraRuntimeError – No per-connection runtime is available.

Return type:

str