Q100490: What are the init.py and menu.py files
This article explains what the init.py and menu.py files are and how they can be used with Nuke.
Nuke allows users to customise vast amounts of the application through its Python API (Application Programming Interface). This varies from changing the colour of Nuke, to setting default knobs values, to changing the entire menu structure and automating Nuke script creation. This customisation ability makes Nuke very useful and powerful in studio pipelines.
Most of these type of customisations can be run in Nuke’s Script Editor. For example, if a user wanted all ColorCorrect nodes that were created to have a Gain value of 2 by default, then running
nuke.knobDefault("ColorCorrect.gain", "2") in the Script Editor would do this for all future ColorCorrect nodes created in that Nuke session.
However, the next time a different Nuke session is launched, the default Gain value of newly created ColorCorrect nodes would be 1. In order for these default value changes to be permanent, the knob defaults need to be set for each Nuke session, using a startup script.
Startup scripts are Python scripts which are run when Nuke is launched, and can be used to run commands like
nuke.knobDefault("ColorCorrect.gain", "2"). This means that any future sessions of Nuke will create ColorCorrect nodes with the Gain knob set to 2.
STARTUP SCRIPT LOCATIONS
Nuke searches for startup scripts in any path listed in the Nuke plug-in path. The default Nuke 12.2v1 plug-in paths are as follows:
'C:\\Program Files\\Common Files/Nuke/12.2/plugins'
The current set of plug-in paths Nuke is using can be found by running the below command in the Script Editor:
Nuke scans for startup scripts in the reverse order of how they are listed, so from the lists above,
Nuke12.2v1/plugins is scanned first, and
<userName>/.nuke is scanned last.
Other paths can also be added to this list by either using the
nuke.pluginAddPath() to add paths to the beginning of the list, or
nuke.pluginAppendPath() to add paths to the end of the list. The plug-in path list can also be edited by modifying the NUKE_PATH environment variable.
INIT.PY VS MENU.PY
Two startup scripts called by Nuke on launch are the init.py and menu.py files. These file names are actively searched for by Nuke in the Nuke plug-in paths and executed when they are found.
- The init.py file is called anytime any Nuke session is initialized, such as Nuke, Nuke Studio or when launching Nuke in terminal mode or even the Frame Server processes.
- The menu.py file is called anytime a GUI version of Nuke is launched, so it is not called for terminal only sessions of Nuke, like the Frame Server processes.
In most cases, customisations should be put in the init.py file as this is called for all types of Nuke sessions, the main exception being anything GUI related, such as creating custom menus or adjusting Nuke’s default menus.
Nuke processes the plug-in path by first looping through the entire list of plug-ins in reverse order, looking for all init.py files and executing them. Next, it will loop through the entire plug-in paths list again, looking for menu.py files and executing them.
USING DIFFERENT STARTUP SCRIPT DIRECTORIES
Although Nuke scans through all of the directories in the plug-in path, Nuke does not automatically create the init.py or menu.py files. Some directories like
Nuke12.2v1/plugins already have one, but for the other paths, they will need to be created.
Most users add the init.py and menu.py files to their .nuke directory, the first path in Nuke’s plug-ins path list. As the .nuke directory is inside the user’s own area, adding the menu.py there will only affect that one user’s Nuke sessions, and there are generally less permission issues than trying to access application install files, so users are less likely to accidentally change something to Nuke’s install.
NOTE: If startup scripts are added to the
Nuke/12.2/plugins directory, then those scripts will affect all version releases of Nuke, so in this case, all Nuke 12.2v# releases of Nuke. If startup scripts are added to the
Nuke12.2v1/plugins/user directory, after creating it, then those scripts will affect that one specific Nuke release.
NOTE: We do not recommend changing the init.py and menu.py files in the
Nuke12.2v1/plugins path, as if these are changed incorrectly Nuke may fail to run or launch as expected.
USING STARTUP SCRIPTS
As previously stated, startup scripts can be used to apply a whole range customisations to Nuke.
One useful function for pipeline environments is
Technical directors (TDs) working on a pipeline can create a series of tools and add them to one path accessible on the network. Users with the plug-in path added will then automatically load the startup scripts from that directory, allowing TDs to adjust a single Python file and roll out tools to the entire company. The main network startup script could then add additional plug-in paths, based on who the user is or other factors, so that other plug-in paths could be included for different users to only get access to show specific tools.
NUKE VS HIERO VS NUKE STUDIO STARTUP SCRIPTS
When Nuke is launched, it scans the Nuke plug-in paths for init.py and menu.py files and executes them.
When Hiero is launched, it scans the Hiero plug-in paths for init.py, menu.py and any other Python files inside
Python/StartupUI directories found within the plug-in paths, then executes them. More information about this can be found here: Q100373: How to add plug-in paths to Nuke Studio and Hiero
When Nuke Studio is launched, it scans the Nuke plug-in paths for init.py and menu.py files and executes them, then the Hiero plug-in paths for the same files as Hiero, and then executes them as well.
When adding extra Python files to the Hiero plug-in path, the files should be checked to make sure that if they are initialled, they won’t cause any adverse reaction when being called on startup. Whereas Python files stored in the Nuke plug-in path will not be initialised unless called specifically by user code.
More information about the init.py and menu.py files can be found below:
We're sorry to hear thatPlease tell us why