PythonBridge

The Python Bridge is infrastructure to run, use and interact with Python from GT.

More specifically, the Python Bridge allows you to send Python code to a Python process running outside GT and get a result back, or just for side effect. A number of primitive types can be transferred directly but in most cases you will work with proxies to the remote Python objects.

The Python Bridge is one instance of GT's LanguageLink framework. As such it offers all kinds of tools to interact with Python at a high level.

The following pages describes the default way to get started as well as a number of alternatives that expose more internal details for advanced use cases.

Getting started with the Python Bridge

This page covers the default onboarding path: external prerequisites (python and pipenv), starting the global PBApplication LanguageLinkApplication << #PBApplication slots: {}; sharedVariables: { #DebugMode }; tag: 'Global'; package: 'PythonBridge' instance, and verifying that the bridge is healthy through inspector details or Python snippets. Read this first when setting up PythonBridge on a new machine, and only jump to troubleshooting if startup or installation fails.

Basic usage of the Python Bridge

This page demonstrates the main usage modes once the bridge runs: programmatic execution through command factories, sending scripts plus result expressions, building commands from Python AST nodes, and using Lepiter Python snippets. It also explains when results come back as native GT values versus proxies, page-level variable sharing, and the performance implications of relying on the unique instance.

Python Bridge troubleshooting

This page is the operations/debugging reference for startup problems. It explains how to diagnose missing or broken pipenv, where the runtime directory lives, how to inspect installation logs, how to manually run the same startup command GT would use, and how to fully reset the runtime environment when you need a clean reinstall.

Using an independent Python Bridge instance

This page shows how to create and manage multiple bridge instances instead of relying on PBApplication>>#uniqueInstance uniqueInstance ^ uniqueInstance . It covers independent ports, starting and stopping ad hoc instances, using them through the same command APIs, and optionally adopting one as the global instance so Python snippets target it.

Running the PythonBridge in another directory

This page explains how to run a bridge from a non-default working directory. The key idea is to create a fresh PBApplication LanguageLinkApplication << #PBApplication slots: {}; sharedVariables: { #DebugMode }; tag: 'Global'; package: 'PythonBridge' , change its settings workingDirectory: before startup, install there, and optionally adopt it as the unique instance so Python snippets and source-file workflows use that alternate runtime location.

Using an externally started, already running Python Bridge instance

This page documents a manual-process mode in which GT connects to a PythonBridge process that you started yourself. It shows how to switch the platform to manual process control, obtain the exact startup command and ports, start/stop the GT side independently of the Python side, explicitly send quit, and then reset the platform back to normal.

Connecting to a remote Python Bridge instance

This page extends the manual-process story to remote hosts. It explains the security implications of exposing gtoolkit_bridge over the network, how to start a remote bridge with --bind-any-interface, how to configure a local PBApplication LanguageLinkApplication << #PBApplication slots: {}; sharedVariables: { #DebugMode }; tag: 'Global'; package: 'PythonBridge' to connect to a remote socket address, what still works through Python snippets after adopting that instance, and which features remain unavailable because the Python executable is remote.

Using an alternative Python Bridge controller process

This page shows a lighter-weight process controller that launches Python directly instead of through pipenv. It is primarily for advanced or experimental setups: reconfigure the platform to use PBPharoDirectPythonProcess LanguageLinkAbstractProcess << #PBPharoDirectPythonProcess slots: { #process }; tag: 'Processes'; package: 'PythonBridge-Pharo' , create a new bridge, start it, verify it works, inspect the small implementation if needed, and finally reset the platform configuration.

Python Bridge cleanup

This page is the shutdown reference. It explains how to stop either the unique instance or a specific bridge instance, where to confirm shutdown in the inspector, and notes that quitting the GT image also stops all live PBApplication LanguageLinkApplication << #PBApplication slots: {}; sharedVariables: { #DebugMode }; tag: 'Global'; package: 'PythonBridge' instances.

Phlow for Python

This page explains how Python objects can define inspector views directly in Python using the gtoolkit_bridge package and the @gtView decorator. It summarizes the available remote view builders (list, columnedList, textEditor, columnedTree, forward, empty), shows small examples of each, and points to Remote Phlow as the underlying model. Read this when you want Python-side custom inspectors, not just code execution.

Debugging remote Python views

This page is a low-level developer/debugging guide for Remote Phlow on Python objects. It walks through defining a Python object with multiple views, wrapping it for remote inspection, fetching view declarations and specifications, and probing list/forward views programmatically from GT. Read it only when developing or debugging Python-defined views and Remote Phlow plumbing.

PythonBridge contextual views for pandas DataFrame and Series

This page is a user-oriented example of adding contextual inspector views for pandas DataFrame and Series objects. It shows where the supporting Python file lives, how to load it into the running bridge, how to ensure pandas is installed, and how to test the result on a sample CSV. Read this when you specifically want richer pandas inspection; use the linked internals page only if you need to modify or extend the implementation.

Working with Python source files

This page is about working with Python code as files and source trees instead of only snippets. It explains the runtime working directory and virtual environment, writing and importing simple modules, viewing/editing files through the LSP Python model, extending sys.path or creating symlinks for larger source trees, and even linking the checked-out PythonBridge sources for development. Read this when your workflow becomes file-based or repository-based.

Working with Python Bridge objects

This page explains what actually comes back from Python: primitive values in some cases, but most often PBProxyObject PBObject << #PBProxyObject slots: { #pythonClass . #application }; tag: 'Core'; package: 'PythonBridge' instances backed by Python-side object identifiers. It contrasts the Remote and Proxy inspector perspectives, shows how to access attributes and call methods on proxies, explains the conversion behavior for primitive/composite values, and introduces mirror subclasses of PBProxyObject PBObject << #PBProxyObject slots: { #pythonClass . #application }; tag: 'Core'; package: 'PythonBridge' for adding GT-side behavior and views to specific Python classes.

Python Debugger Setup & Example

Demonstrates starting PBApplication LanguageLinkApplication << #PBApplication slots: {}; sharedVariables: { #DebugMode }; tag: 'Global'; package: 'PythonBridge' with the python debugger enabled.