NukeCTL and CTL_MODULE_PATH

[mfe]

CTL_MODULE_PATH env var seems to have to be set before launching Nuke such as imported modules of a CTL script could be found by NukeCTL node.

This can be annoying if different versions of the same transformation co-exist in CTL_MODULE_PATH.
Precise use case : comparing different versions of ACES RRT that have to import corresponding utilities modules.

Shouldn't CTL_MODULE_PATH be set automatically or in a transparent way ?

For what it's worth, in TuttleOFX CTL node, imported modules are searched in the directory of the loaded CTL.

[aforsythe]

Is searching for imported modules in the directory of the loaded CTL effectively the same as setting a different CTL_MODULE_PATH for each CTL node?

Would it be better to have a default CTL_MODULE_PATH for each node (either one based on the environment variable, or based on the loaded CTL directory) and an override for each node where the CTL_MODULE_PATH can be set?

I'm just thinking out loud.

Alex

Alexander Forsythe - Imaging Engineering Manager - Science and Technology Council

Academy of Motion Picture Arts and Sciences - Tel 310-247-3000 x3310
Fax 310-247-3611 - www.oscars.org - aforsythe@oscars.org

On Aug 1, 2013, at 6:00 AM, Marie FETIVEAU notifications@github.com wrote:

CTL_MODULE_PATH env var seems to have to be set before launching Nuke such as imported modules of a CTL script could be found by NukeCTL node.

This can be annoying if different versions of the same transformation co-exist in CTL_MODULE_PATH.
Precise use case : comparing different versions of ACES RRT that have to import corresponding utilities modules.

Shouldn't CTL_MODULE_PATH be set automatically or in a transparent way ?

For what it's worth, in TuttleOFX CTL node, imported modules are searched in the directory of the loaded CTL.

—
Reply to this email directly or view it on GitHub.

[mfe]

In TuttleOFX, we didn't need to customize CTL_MODULE_PATH to handle local imported CTL. I guess it's because our code use the loadModuleRecursive function.
_{(JFI : TuttleCTL is still using master branch of CTL, I'll switch asap)}

In NukeCTL code, loadFile function is used but it doesn't seem to call the recursive version of loadModule func (I just had a quick look so I may be mistaken).
So may be, there's sthg to check here ?

A good concession might be to make the node look first in the directory of the loaded CTL and then in the CTL_MODULE_PATH.
Thus in most cases, the user wouldn't need to worry about setting a CTL_MODULE_PATH before launching Nuke... And if he wants to load scripts that needed some common modules that are in a different location, he still have the possibility to customize the paths.

I wonder if it could be an idea to allow the user to modify CTL_MODULE_PATH in the node GUI too. But I'm not sure that an environment variable could be effectively modify once Nuke is launched (or once the node is created).

I'm also thinking out loud :)

[JonCG90]

loadModuleRecursive is called by the parser (it has an instance of the interpreter). I am currently adding a knob to set the module path per ctl node. I will let you know when it is finished.

[kgboreham]

I'm just thinking too...

Recursive load should work. I think it should check the current directory then the ctl_module_path. That's what I would expect.

Also - Probably ctl_module_path should support multiple paths with a delimiter if it doesn't already.

There are some tricky problems that can arise for the user but normally should be okay.

On Aug 14, 2013, at 4:51 PM, JonCG90 notifications@github.com wrote:

loadModuleRecursive is called by the parser (it has an instance of the interpreter). I am currently adding a knob to set the module path per ctl node. I will let you know when it is finished.

—
Reply to this email directly or view it on GitHub.