Python Bridge troubleshooting

There are two issues that sometimes come up with the Python Bridge infrastructure.

pipenv not found

The first issue is that the location of the pipenv executable cannot be found automatically, maybe due to a non-standard installation or setup. This will give an error when GT tries to start the Python process.

You can find out which path GT thinks it should use.

PBPharoPipenvPathFinder pipenvPath
  

You can override the path manually.

PBPharoPipenvPathFinder pipenvPath: 'C:\Users\sven\AppData\Local\Programs\Python\Python312-arm64\Scripts\pipenv.exe' asFileReference
  

Implementation

The automatic pipenv path detection in PBPharoPipenvPathFinder Object subclass: #PBPharoPipenvPathFinder instanceVariableNames: '' classVariableNames: 'PipenvPath' package: 'PythonBridge-Pharo-Processes' relies on GtOsSystemInfo>>#findExecutable: findExecutable: aString "Do a `which` on the supplied executable name Run this in a shell to ensure that all logon configuration is performed and the PATH is fully expanded." | shell builder output path | shell := Smalltalk os environment at: 'SHELL' ifAbsent: '/bin/sh'. builder := GtExternalProcessBuilder new command: shell; args: { (shell endsWith: 'csh') ifTrue: [ '-d' ] ifFalse: [ '-l' ]. '-c'. 'which ', aString asString }. output := builder output. output status isSuccess ifFalse: [ ^ self error: 'Unable to find: ', aString asString, ', process failed to run' ]. path := output stdout trimBoth. path ifEmpty: [ self error: 'Unable to find: ', aString asString, ', executable not found' ]. ^ path asFileReference or GtWindowsSystemInfo>>#findExecutable: findExecutable: aString "Do a `where` on the supplied executable name" | builder output path lines | builder := GtExternalProcessBuilder new command: 'where'; args: { aString asString }. output := builder output. output status isSuccess ifFalse: [ ^ self error: 'Unable to find: ', aString asString ]. path := output stdout trimBoth. path ifEmpty: [ self error: 'Unable to find: ', aString asString ]. lines := path lines collect: [ :line | line trimBoth asFileReference ] thenSelect: [ :each | #(bat exe) includes: each extension asLowercase ]. lines ifEmpty: [ self error: 'Unable to find: ', aString asString ]. ^ lines first. in the case of Windows. For macOS and Linux, a login shell will be used so that the widest possible PATH is searched - even in the case when GT was started with a more limited PATH as happens on macOS when double-clicking the GT executable.

Note also that the pipenv path is cached inside PBPharoPipenvPathFinder Object subclass: #PBPharoPipenvPathFinder instanceVariableNames: '' classVariableNames: 'PipenvPath' package: 'PythonBridge-Pharo-Processes' . You can flush this cache with PBPharoPipenvPathFinder>>#reset reset self pipenvPath: nil .

pipenv not working

The second issue is that pipenv does not work properly. This is a problem external to GT and should be resolved there.

The location where the bridge infrastructure gets installed to and run from is next to the GT image and is called PythonBridgeRuntime. This is a fixed location.

PBPlatform current defaultSettings workingDirectory
  

The PythonBridge uses a virtual environment in that directory. You could navigate into that directory and manually try to install gtoolkit_bridge using pipenv. You can try the command that GT will use to start the bridge (see also Using an alternative Python Bridge controller process).

$ pipenv run python -m gtoolkit_bridge --port 7007 --pharo 7006 --method msgpack --log

If all is well the output should be similar to the next log.

PythonBridge starting {'port': '7007', 'pharo': '7006', 'method': 'msgpack', 'log': True} HANDLER (MsgPackSocketPlatform): loop func PythonBridge ready PYTHON: Start consuming commands

log files

Inside the PythonBridgeRuntime working directory there should be two log files: complete.log and install.log.

The first log file, complete.log, is written at the end of the initial bridge installation process and marks its successful completion. It contains a timestamp when the installation was completed.

The second log file, install.log, has a line for each Python module that got installed through pipenv, with a timestamp and duration.

starting over

When something goes wrong during the automatic installation of the PythonBridgeRuntime and your make changes, or when there are updates to the bridge's Python code, it might become necessary to start over. You can do that by simply deleting the whole directory.

PBPlatform current deleteRuntimeEnvironment
  

With the way pipenv virtual environments are managed, it could also be useful to delete that as well. This can be done using PBNewPharoPipenvProcess>>#deleteInstalledVirtualEnvironment deleteInstalledVirtualEnvironment "pipenv virtual environments are just directories. they are named after the directory they were created in with a hash of the path to it. PBNewPharoPlatform>>#deleteRuntimeEnvironment is not enough to delete the virtual environment that is often stored somewhere else. to really start over, call this method first" self installedVirtualEnvironment asFileReference deleteAll . You can get a handle on this object by inspecting PBApplication > Internals > (process handlerl) > Details > (process).