The bootstrap script use rez under the hood. The actual version of the DCC to use is determined by the bootstrap process and is not known by the Deadline job.
I’m having a hard time making this workflow work. Deadline expect plugin RenderExecutable method to return a “rooted path”. For example, if I have a custom nuke plugin that does:
def RenderExecutable( self ):
return "nuke"
I’ll get:
INFO: File "nuke" is not rooted, checking current directory
INFO: File "nuke" is not rooted and is not in the current directory, checking PATH
INFO: File "nuke" is not rooted, is not in the current directory, and does not exist in PATH
Is there any way to control this behavior? The Deadline process won’t find nuke in PATH and that’s okay. The actual executable once ModifyCommandLineCallback is called will be /path/to/bootstrap and nuke will be resolved by the rez sub-shell.
We are indeed very interested in the rez integration and will check it out as soon as we update from 10.1. That being said what I’m trying to do here is get the rez request dynamically so the rez plugin won’t help here as it assume an already built request.
Since we are using custom plugins for everything, I’ve been able to workaround the problem by:
Implementing a GetRenderExecutableForRez method in our plugins. This method return simple value like maya and nuke which match our rez aliases.
Made ModifyCommandLineCallback ignore the render executable provided and use the one returned by GetRenderExecutableForRez instead.
Created empty executables on the network (ex: /{deadline_repository}/custom/bin/maya and pointed our plugins to them so Deadline won’t trigger the “File is not rooted” error.
As you can see, this is cumbersome and I would love to have a better solution. Let me know if you have any ideas. I’ve also tried calling RenderExecutable from inside ModifyCommandLineCallback but it got hairy fast when dealing with managed plugins.
I think our use case is valid and we should be able to tell a plugin to accept non-rooted path. Would love to see the ability to do so in a future release.