Nuke command line and python environment

When I launch nuke in gui mode I run a python script at startup by feeding the first the py script as the first argument to the executable
CMD >> Nuke8.0

Within this file I am determining paths based on environment variables and doing

Functions within this module can create auto write nodes that name themselves according to our naming convention and auto make their output folders if they don’t exist, so a render doesn’t fail.

All of this works within the gui.

When setting up a python render script for Rush render queue, I’m using the nuke python interp (python.exe from within the nuke install folder)
so that from within that interp i can use the nuke module
(I started the standard way of just trying to launch the nuke executable with the -x option but had many more issues there. I’d like ot )

My rush script does all the same stuff my startup script does, adding paths to sys.path
But when I use something like
myModule.makeOutputFolder() as the prerender python script of a Write node, it claims that myModule is not defined, and the render fails.
How is this possible???

Here is a very simple version of what I’m doing in the render side of my rush script

import sys, os
import nuke

os.environ['NUKE_GIZMO_PATH'] = GIZMO_PATH       # This works and nuke will find my gizmos


import myModule                                  # This works, and the current env can use it,
                                                 # but if the nuke script uses it, it can't find it

nuke.execute("myWriteNode")                      # Fails because writeNode can't find myModule

Its as if nuke.execute() does not work within the same environment so it doesn’t have the same modules imported

Why would it have access to os.environ but not have access to modules already imported?

I’m puzzled.

Windows 7 x64

Hey there,

is there any specific reason why you are feeding a python script on the command line? To set up your environment and UI etc. you’d typically use and Usually these would reside on a central server and you just point NUKE_PATH to a directory containing these to evaluate them. is used to do setup work that is always needed (like setting up additional plugin paths or alike. Always as in both GUI mode and headless). contains things needed for the gui. Setting up your menus (hence the name i guess hehe) setting knob defaults and callbacks and shortcuts etc.

I don’t really have the time to give your specific use case a try, but using the new “import nuke” feature comes with some limitations (e.g. it strips sys.argv on import).


For reference:
Startup Scripts and execution order:

To be clear, I’m feeding a py script to the executable when launching the gui
This is what is working!

What isn’t working is starting the nuke python interpreter,
Importing myModule
Then being able to use it within the nuke script. (like on a write node)

The reasons I’m not just adding these things to the and files is because…
I have way more going on than just nuke.
Postgres database
GUI tools using pyside and Qt that are accessible in any program we use
Maya tools that link into these things also
Setup for multiple developers (even though I’m the only one at the moment) So paths have to be dynamic
A git repository for my version control on the whole system

I also wanted to preserve the ability to launch a default setup of nuke, no plugs, no database requirements, etc…

but mainly…
I thought they were local (either user folder or install folder) - hence I’d need to update every machine when a change was made which is not acceptable

I was not aware of the NUKE_PATH variable… i’m investigating it now.
oddly enough as a temporary measure I made my own NUKE_PATH variable to point to the nuke install folder
(meant as a placeholder for a dynamic method to handle version requirements)

I’m 99% sure NUKE_PATH will work for my gui launch
and I think it will work in rush / the py interpreter… time will tell and I don’t know if I’ll have the time today to test it out

Thanks for pointing me to that.

Actually using NUKE_PATH is quite flexible. You can have multiple paths there. So you can have different NUKE_PATHs for different parts of your toolset and then chain together only the parts you want. As it’s an env variable you can also nicely do that per session only. Pretty much using anything from a .bat file, to starting from a .py script or calling the shell from your native application or maxscript/mel/whatever. So you can basically:

  • Leave NUKE_PATH empty on the boxes
  • Before launching nuke set up the environment to you need (set NUKE_PATH to something like “//server/share/basetools;//server/share/show-specific-tools;//server/homedir/personaltools”)
  • Launch Nuke

Inside of you can also nicely add different plugin paths for different nuke versions if you want this on the nuke side rather than your wrapping scripts.