Native Python Environment Support

It’d be great if TD’s Python executed in a virtual environment.

It’d be great if that venv lived somewhere outside of the TD install directory, somewhere standard, and it persisted between installs. It’d be great if we could source that venv with processes running outside of TD and install to it in a similar fashion.

It’d be extra-great if there were an ‘Environments’ dialog where you could manage multiple venvs within TD, create new ones, delete them, change source on the fly, and freeze them so you can bundle your freeze file with your .toe, or load a freeze file to create or update a venv.

That way we could make projects that have external Python dependencies extra-portable while also having clean and controlled environments on a per-project basis, if necessary.

1 Like

+1 I think this could also be a big feature addition for private components as well. Currently we basically just ship all the Python libraries in a folder and have to move it into the TouchDesigner install folder then add it to the sys.path. Would be great if something like pip was exposed for the environments Noah mentioned, then custom components could just invoke pip, see if the libs they need are already available in the environment, and if not just do a pip install for the package.

In terms of freezing, I think that could be an avenue too if VFS was expanded to hold arbitrary data and you could freeze your whole lib into a tox and then ship that.


I spent a bit of time looking at this, and the issue is that TD doesn’t launch a python.exe, TouchDesigner.exe IS python.exe for all intents and purposes. So the venv tools that Python provides don’t really help us with this. You’d need a different TD installation for each of your venvs.

The other issue is that we have some custom changes we do to pythons main .dll to improve speed, so using a different python35.dll that comes from elsewhere won’t work with TD.

All we can really do is provide better tools to manage module search paths, but the actual python compiled code (python35.dll etc.) needs to stay the same in all cases.

How about macOS? Is it possible on a mac?

Situation is the same on both platforms