Hi Phil,
I think what I’m trying to do is make a more robust and software agnostic approach(and maybe more portable). Your suggestion makes sense for renders, but less so for publish jobs which do require SG. Perhaps I’ve not hit any issues with bootstrapping all slaves as I’m not scaling in a big way yet?
You’ve not quite followed my thinking in your summary.
(1) Correct, I am using the pre job script to setup SG.
(2) Bundle cache path could be either centralised or local depending on whether in-house or remote user. I’m trying to ensure either would work.
(3) I am bootstrapping tk-nuke as, perhaps incorrectly, I’m trying to create a setup that simply recreates a local workstation environment. Adding the tk-nuke/classic_startup to NUKE_PATH appears to work fine for launching Nuke with SG working as expected. I’m no longer doing anything special to ensure the gizmo is pulled down as including classic_startup in NUKE_PATH does this for me. I’m no longer getting the gizmo path as classic_startup (well, engine.py) is adding any gizmo paths to nukes pluginpath on startup for me.
The only issue with the gizmo not being setup is the fact Nuke was launching in to “shot” not “shot-step” from the provided context entity. Perhaps I’m pulling the wrong entity from the context here? I’ll need to investigate that. Adding the write-node app to shot and asset envs resolves this issue anyway.
I think perhaps one thing I’ve not described in detail here, is that we are using SG to handle non-SG software packages; eg custom python libraries, dcc configs, 3rd party libraries etc. We upload these to SG as toolkit bundles, and have a custom method for caching them locally and adding them to the environment. On workstations, this is handled in engine_init and app_launch hooks. On the farm, we need to do the same; so we do need to instanciate tk-shell, so we can grab the correct toolkit bundles, caching them locally, and runninig their app_launch hooks to prepare the environment.
It works really well for us and makes developing, version control, and configuring quite straight forward. Given we have to instanciate tk-shell on the job pre-load, then it makes sense to pass the engine bootstrap path to the DCC to let SG do all the work of preparing the SG environment on the DCC. I get the feeling this approach is against the ethos of SG?
Shall we do a screenshare so I can walk you though this setup. I’m clearly not doing a good job of describing things here 
Thanks again
p.