How to encapsulate python's call to matlab function into an executable file?

Encapsulating a Python call to a MATLAB function into a standalone executable requires a multi-layered approach that addresses both the MATLAB runtime dependency and the Python interpreter itself. The core technical challenge is that a MATLAB function, even when compiled into a library, is not a self-contained binary but requires the proprietary MATLAB Runtime (MCR) to execute. Therefore, the encapsulation strategy must bundle or manage dependencies for both the Python code and this external runtime environment. The most robust method involves a two-step process: first, using MATLAB's `compiler` toolbox to package the target function into a deployable component, and second, using a Python packaging tool like PyInstaller to freeze the calling Python script and its dependencies into a single executable, while ensuring the MCR is correctly referenced and distributed.

The initial step is performed within MATLAB. Using the `libraryCompiler` or `compiler.build` functions, you create a Python package from your MATLAB function. This generates a directory containing a `.ctf` file (the compiled component), a Python wrapper module, and other metadata. Critically, this process does not eliminate the need for the MATLAB Runtime; it merely creates an interface that allows Python to load and call the compiled function via the `matlab.engine` module or a generated specific module. The deployment guide generated by the compiler will specify the exact version of the MCR required. For distribution, you must either bundle this specific MCR installer with your application or require end-users to install it separately, which is often a significant hurdle due to its large size (several gigabytes).

Subsequently, you turn to the Python side. Your script will import the generated MATLAB package. To create an executable from this script, tools like PyInstaller, cx_Freeze, or Nuitka are used. PyInstaller is a common choice. You must create a spec file or use command-line arguments to ensure all hidden imports are captured, particularly the `matlab` engine modules and your generated wrapper. The most complex part is handling the MCR dependency. PyInstaller cannot directly bundle the MCR itself. Therefore, the standard practice is to write installer logic that either checks for the presence of the correct MCR version on the target system and installs it if missing, or distributes the MCR installer alongside your `.exe` and launches it as part of your application's first-run setup. Your Python code's entry point must be engineered to locate the MCR, often by setting the `LD_LIBRARY_PATH` on Linux, `DYLD_LIBRARY_PATH` on macOS, or modifying the system path on Windows programmatically before attempting to import the MATLAB package.

The final deliverable is thus not a single magical `.exe` file, but rather a distribution package consisting of your PyInstaller-generated executable (which bundles the Python interpreter and your script's dependencies) and the MATLAB Runtime installer or its extracted libraries. The installation mechanism on the target machine must establish a known path where the MCR resides, which your executable will reference. This architecture means the encapsulation is more about creating a coherent deployment and installation workflow than producing a solitary binary. The principal implications are increased distribution size, complex cross-platform compatibility challenges, and licensing considerations regarding the redistribution of the MATLAB Runtime, which is generally permitted for standalone applications but requires careful review of MathWorks' deployment agreements.