Thanks Philip.
We’re already using before_app_launch.py in SGTK to do all the pre-launch environment setup, per application. Eg. setting license details, setting HOUDINI_PATH or NUKE_PATH, plugins paths, etc. I’m hoping that I can re-use that same infrastructure to get a working environment ready on the farm.
Currently our farm submission process copies the existing environment to the farm job so it is available when the job starts and all it needs is the path to an executable, but this only works when I want to run the same type of environment that I’m already in (eg. submitting a Nuke job, from a local Nuke). In my current situation I want to be able to for example submit a Nuke job, from a local Houdini. In this case I want to be able to spin up a Nuke environment with all our customised stuff, the same ‘official’ way as if it was launched via shotgun desktop.
One option for this could be to submit a generic script job to the farm that takes care of launching Nuke correctly with all the SGTK environment available.
For 1. I already have a bootstrap setup working properly, but it gets its environment presented to it already, so I’d still need a way to initialise the environment first.
For 3. I saw a post of yours previously mentioning something like this but I can’t see an execute_command() method in the Engine API docs or in the tk-core python files?
But 2. Seems interesting, I just tried it and seemed to work fine. I didn’t even need a Task, it seemed happy to start up in a Project context. I could pass on an environment variable with the path to the tank executable per pipeline configuration on disk so that aspect should be ok.
One thing though, just from what I’ve read while hunting around online it seemed a bit like the tank command was a bit of a legacy thing, and perhaps deprecated? It seems to be associated with some older workflows. Is this the case, and is it safe to rely on this moving forward?
thanks!