Deploying Unity Python Applications

Problem

We lack a robust way to cleanly package and distribute unity applications interfacing with the python back end. To run any given program, the end user must install and run a distinct copy of BCI Essentials in parallel, including the management of a python installation and, ideally, virtual environment. This can be troublesome for less technically oriented researchers and is generally unreasonable for any potential end user outside of the lab.

Any viable solution would provide a way to distribute a Unity application as an archive with a single entry point.

An ideal solution could also provide methods of automating this process with releases.

Possible Solutions

Listed in rough order of viability:

Python → Standalone Executable (CLI)

It is possible to “build” or “compile” a python program to a standalone executable with no external dependencies. This could provide a highly portable discrete release version of the python back end that could easily be shipped with any Unity build as a portable dependency. The “python program” in this case would be a new core script that relies on command line options to reproduce the behaviour of any existing example script according to the provided configuration parameters. Additional communication could be read directly from stdout.

Multiple tools can accomplish this:

• PyInstaller
• py2exe
• Nuitka

Considerations

• Requires a translation of all configuration parameters into command line flags
• Necessitates a central python script to dynamically configure modes from different command line arguments
  • selects and configures the eeg/marker source, paradigm, and classifier
  • implements standard parameters like --help and --version
  • handles parameter validation, providing informative error messages
• Certain fine parameters, such as numerical arguments passed to the classifier, may be somewhat cumbersome to include on the command line
• Would require the extension of the unity front end to start and monitor this external process
• Highly dependent on error handling
  • keeping the back end alive
  • manage back end crashes in Unity

Standalone Local Python Web Server

A variation on the previous, using http requests (or web-sockets) to facilitate configuration and ongoing communication. The same tools and similar considerations apply. Could theoretically provide more structure to configuration/run commands. However, modern tools/libraries available for implementing command line arguments likely allow for a more robust solution to be implemented with significantly less overhead compared to the manual validation of, and response to, a request body.

Calling Python Code From Unity

It is possible to invoke python code directly from Unity using tools like Iron Python. These tools are often limited to a defined set of libraries with which they have been compiled in order to avoid external dependencies. However, it may be possible to circumvent this constraint by compiling the back end code as a redistributable python library, which could then be used by a plain python script with no other dependencies. This could allow the Unity front end to define and run it’s own back end scripts.

Considerations

• Python needs to be packaged somehow along with the program
• Requires a significant external dependency on Iron Python or a similar tool
• May not even be possible

Python → C/C# Library

It would be incredibly convenient to be able to pack the python back end into a dll that could be directly used in Unity as a plugin. However, this does not seem to be possible without embedding the python interpreter.