FIXED: 2025.30060 tdPyEnvManager order of initialization

[dylanroscover]

hi, this may or may not belong in “bugs” depending on how one looks at it.

the environment does not appear to be made available on toe start (or, more specifically, before everything else starts to initialize), even though it is configured properly and reports the Environment linked and ready:

if I turn off cooking for the component in question:

and then re-enable cooking:

it loads the missing modules.

looking further down my textport logs, I notice that the manager loads well after many other portions of the app:

2025-06-11 07:59:58,658 - INFO - TDAppLogger.tdPyEnvManager_logger - PID:43465 - /Aleph/lib/tdPyEnvManager - Environment /Users/rosco/wkspaces/2412-ldi/Aleph2/Aleph2_vEnv was linked and is ready. Context is: {'type': 'Python vEnv', 'envPath': '/Users/rosco/wkspaces/2412-ldi/Aleph2/Aleph2_vEnv', 'executablePath': '/Applications/TouchDesigner.app/Contents/Frameworks/Python.framework/Versions/3.11/bin/python3.11', 'osPath': [], 'sysPath': ['/Users/rosco/wkspaces/2412-ldi/Aleph2/Aleph2_vEnv/lib/python3.11/site-packages']} (DAT:/Aleph/lib/tdPyEnvManager/TDPyEnvManagerExt, fn:linkEnv, ln:962, absFrame: 0, frame: 533.0)

as per the Considerations documentation, all extensions are not set to init onStart – only tdPyEnvManager is:

the expected behavior here would be that the vEnv is available immediately onStart, before everything else… is there a way to force this to load prior to everything else, or is the expectation here that the user needs to init all vEnv calls (extensions, etc.) with built-in delays?

which leads me to a more profound question: what determines the load order for components in a toe, and is there / could there be a way to set this order more efficiently than dozens/hundreds of run() delays?

thanks!

[JetXS]

Hi @dylanroscover

The way you’ve setup everything sounds fine and it should have been working smoothly.

The Extension init onStart toggle makes it so that this particular extension actually compiles before an Execute DAT onStart triggers, if I am correct. I will confirm with devs.

Therefore, any other extension that compiled should have compiled after the TDPyEnvManager, unless they had the toggle turned on.

The toggle can be turned on in other components, so long that they don’t rely on the TDPyEnvManager setup.

We hope in the future to improve this to prevent issues.

Will try to reproduce your case.

Best,
Michel

[JetXS]

Hey @dylanroscover

While we are investigating solutions for a more bulletproof approach, I wanted to find a case to reproduce this.

I’ve been unable to reproduce the issue so far, although I am trying to get as close as possible to your setup.

Including different components at different levels, no project1.. etc

I am wondering if you could point anything like: are you using externals, clones, synced to disk extensions… etc

Thank you for your time,

Best,
Michel

[dylanroscover]

Our setup has dozens of extensions. It’s the most complicated project we’ve attempted to wrangle to date, so I doubt you’ll be able to replicate under simplified conditions. I can probably just email the project.

Here is what I’ve done to “fix” it in the meantime:

op.ui.op('canvas/creator').allowCooking = False
run("op.ui.op('canvas/creator').allowCooking = True", delayFrames = 120)

[JetXS]

@dylanroscover

I’m assuming that’s some UI / panel COMP ? and it’s cooking before the PyEnvManager… Which should not happen, but I’ll confirm with devs.

We are working on a solution for something more reliable regarding the initialization of the TDPyEnvManager and environment setup.

Best,
Michel

[dylanroscover]

Hi @JetXS, any updates?

[JetXS]

We are working on a solution internally.

Not quite there yet but hopefully soon!

[dylanroscover]

Hi @JetXS, I may log this in a separate proper RFE thread, but worth noting here, too.

I think that whatever you all are working on ought to be exposed to users, so that we may set a precise order of initialization. Perhaps a new parameter, Init Order, that lives on each COMP?

My team is running into a myriad of issues with an extremely complicated project we have been working on for a little over 1.5 years now. Many of our issues stem from initialization ordering issues. The ability to control initialization of a network in a non-hack way would be, in my opinion, of the utmost benefit for your advanced user base.

[JetXS]

Yeah Dylan that should be a different RFE please. If there is not already one actually…

I understand the issue, it’s something on the back burner.

What we are working on here for TDPyEnvManager is a bit different because it’s a startup thing, before any TouchDesigner components and extensions are being initialized.

Best,
Michel

[JetXS]

This feature is implemented in our latest official 2025.30000+ release.