I agree with Nathan I would want a fresh session of Nuke if I switched. Doesn't close, which launches a new nuke session and reloads a menu.py init.py do what you want?
I have a basic tool for switching projects, which closes nuke (or opens a new nuke) and picks up the project directory, so from then on Nuke is set to project B. Should be simple enough to then load the init etc... Howard > On 2 Oct 2013, at 01:54, Jesse Kretschmer <je...@krets.com> wrote: > >> On Tue, Oct 1, 2013 at 5:38 PM, Nathan Rusch <nathan_ru...@hotmail.com> >> wrote: >> If all you need to do is make some decisions based on the script that’s >> being loaded, why not just install an onScriptLoad callback, parse the >> appropriate show/shot out of the incoming path, and pass them to a bootstrap >> function somewhere to take care of the modifications to the environment, >> plugin path, etc? No need for any init or menu files or exec-ing. > > An onScriptLoad callback is triggering the code that executes the menu.py and > the init.py for the project, along with our project switcher. This feature is > meant to enable the technical artist to self-serve without direct support > from the pipeline department. This allows them to offer custom python code > and menu options to the other artists on the project. I'd like to contain > these customizations to primarily gizmos, but there have been many requests > to support knob defaults and default formats which is easier handled through > a menu.py. > > My primary goal is to sandbox these changes to a specific project. Core > pipeline tools can only be altered by the pipeline department. Any project > specific code will only affect those artists in the project context. We have > been a little loose with edits up until my recent environment changes. > Occasionally a well-meaning artist would apply a global change that would > stop nuke from loading. > > Plugin builds are not being changed, and there is no plan to do this with our > setup. I do understand that each context switch will further dirty the > session, but for the most part each context switch is adding gizmos and menu > items. There may be reason to be concerned about conflicting python module > names and gizmo names that are used throughout these projects, but I'll cross > that bridge when I come to it. > > > _______________________________________________ > Nuke-python mailing list > Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
_______________________________________________ Nuke-python mailing list Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
