Introducing the TouchDesigner Python Environment Manager (TDPyEnvManager)
I’m kinda new to utilizing rather in-depth Python functionality in TD and not quite sure if this is the right place to ask this question, but I’m guessing that newbies like me are likely to be coming across the same obstacle, so here goes the question.
I used Alphamoon’s TD pip tox file to implement a similar virtual python environment for incorporating ‘easyocr’ library into TD, which requires numPy and other basic libraries with later versions than the ones used by the native python that comes with the TD version I’m using(2023.12120).
I’ve successfully imported the ‘easyocr’ into my TD under the new python virtual environment, but it crashes as soon as a Script TOP cooks. (Which utilizes numPy, and I suspect the version mismatch to be the cause)
Could TDPyEnvManager run simultaneously along with the native TD python side by side without any compatibility issues? Or at least switch back and forth to avoid any collision?
Taking the most out of both TD and external Python functionality simultaneously would be an ideal world for me, really, but I’m not sure if that’s something possible at this point, though…
Hey @barmoon7
The issue you are facing is a known issue and indeed caused by a version mismatch with NumPy in TouchDesigner builds 2023.12120 and above, on that specific branch.
The issue is fixed in current experimental builds 2025.30k+.
To answer your question, not really.
The TDPyEnvManager is designed to create virtual environments out of TouchDesigner’s own Python, which guarantee the same python version to be used and link back to the same python interpreter.
When using the Conda mode, this is also designed to create conda environments matching TouchDesigner’s own Python version, to maximize compatibility and avoid some version mismatch issues.
You could use the conda mode to run both TouchDesigner, and another Python process, in parallel, but you would have to design the whole data exchange between both processes.
Best,
Michel
Thanks for the quick reply! but could you clarify on how the issue is fixed?
No matter what the version of Python a certain TD version runs, it’s still bound to that one specific Python version isn’t it? So, under my understanding, there still lies a possibility of TD crashing as along as the numPy version of the newly incorporated venv Python does not match the numPy version of the Python native to TD.
I suppose the experiment builds come with relatively version of new Python/numPy/etc, but they’ll get outdated at some point or if I need to use libraries that use older versions of numPy/etc, the version mismatch is still there in either case no?
I’m curious if TDPyEnvManger can be run via an Engine COMP so it can be run on a separate thread and never collide with the main TD project and if that doesn’t work, I guess I’ll have to run two separate TDs and let them comm. through OSC or something instead.
In any case, I’m really grateful for your contribution to the TD and it will benefit everyone in so many ways really!
It’s unlikely that the crash would occur, as this is the fixed issue here and if it’s erroring because of this, it’s clearly stated in the info dialog.
I suppose the experiment builds come with relatively version of new Python/numPy/etc, but they’ll get outdated at some point or if I need to use libraries that use older versions of numPy/etc, the version mismatch is still there in either case no?
Yes, builtin packages were updated with experimental.
If they get outdated, you are free to sideload a vEnv using the TDPyEnvManager and upgrade the package you wish to be upgraded. In most cases, if it’s a minor version update, this would not cause issues.
If you need to use libraries that use an older version, and where the version requirement is that strict, then I’d suggest to ask the library developers to do the update, or tweak the requirements to be a bit more permissive if at all possible. Last, you can run this in parallel to TouchDesigner…
I’m curious if TDPyEnvManger can be run via an Engine COMP so it can be run on a separate thread and never collide with the main TD project and if that doesn’t work, I guess I’ll have to run two separate TDs and let them comm. through OSC or something instead.
No. The Engine COMP still run the same python interpreter that ships with TouchDesigner. There is no way around that.
Python is tightly integrated to TouchDesigner. The builtin libraries we ship are production tested, and tightly integrated within multiple parts of TouchDesigner. The TDPyEnvManager just makes things easier to work around and more permissive.
But this is not a magic solution that works around TouchDesigner’s own architecture and Python’s best practices.
Thanks for the reply and your support! You’ve cleared up a lot of the question marks I had about TD!
Another great addition to TD!
Exactly when I need it, perfect timing ![]()
I try it right now, thanks a lot for your work!
Is it possible to link an existing venv?
For our project, TD is part of the setup, but not necessarily the main component - thus we develop and create code in a venv which we’d like to use in TD. Right now we’d just specify it in the settings, but being able to use this component would be great. However, it looks like this only supports creating a new venv?