Plugin having a hard time initializing (Nuke)

[jjsa]

Running Nuke9.0v6 and when i try to run Nuke after installing the plugin i get a error

/Library/Application Support/Nuke/9.0/plugins/Cryptomatte/init.py

error interpreting the plugin

If i try run Nuke using the full path to the app, the plugin loads successfully

/Applications/Nuke9.0v6/Nuke9.0v6.app/Contents/MacOS/Nuke9.0v6

Any thoughts?

[acjones]

Usually this sort of thing is due to an incorrect download from github (it's come up before, as github isn't super user-friendly for people who aren't used to using it. A lot of people try to right-click, save-as, but that doesn't really work). Would you mind double-checking that you followed all the the "Nuke Installation" directions on the main project page?

[jjsa]

thanks for the quick response. i downloaded the zip twice just to confirm (checksums were the same). again it does seem to work as long as i launch nuke via the full path but if i try to launch nuke via spotlight search i get the error. same behavior from the launchpad

[jjsa]

since i created a new directory for the plugin there was no merging of init and menu needed i added the new path to the NUKE_PATH and confirmed that it was there by starting up nuke in terminal mode and checking nuke.pluginPath()

[acjones]

Ah, okay. Sorry, I should have read your initial post more thoroughly. All the init.py does is import a python module and run a function from it. So if it's complaining about init.py, it seems likely that something is different with the python search path between the two methods of launching. Unfortunately I'm not on a Mac, so it's a little tough for me to confirm any differences between launch behaviors... Can you run the following code in the script editor for each of your launch methods, and post the output? (The code should all be on one line in the script editor, as I noticed pasting out of this comment dialog doesn't format correctly.)

import os, nuke;print 'PYTHONPATH:\n%s\n\nNUKE_PATH:\n%s\n\nnuke.pluginPath:\n%s' % (os.environ['PYTHONPATH'], os.environ['NUKE_PATH'], nuke.pluginPath())

[jjsa]

thanks again for the feedback. not familiar with doing the steps you requests in the script editor. i have opened up the script editor on the mac and pasted in your code you provided above

i see an option for javascript and applescript. when i run it errors both ways

sorry for all the questions

[acjones]

Sorry. I meant the script editor in Nuke. (If you're not sure how to use to the Nuke script editor, check out page 848 in the Nuke User Guide, or this link.

[jjsa]

thanks for the clarification. this is what i get it i startup nuke full command line so it loads cryptomatte

import os, nuke;print 'PYTHONPATH:\n%s\n\nNUKE_PATH:\n%s\n\nnuke.pluginPath:\n%s' % (os.environ['PYTHONPATH'], os.environ['NUKE_PATH'], nuke.pluginPath())

Result: Traceback (most recent call last):

File "", line 1, in File "/Applications/Nuke9.0v6/Nuke9.0v6.app/Contents/MacOS//../Frameworks/Python.framework/Versions/2.7/lib/python2.7/UserDict.py", line 23, in getitem raise KeyError(key) KeyError: 'PYTHONPATH'

if you want me to run the same with nuke starting from the launchpad, i will need to remove the cryptomatte script since it will not startup nuke once it hits the error

[jjsa]

sorry ... this is the correct output that i get

[acjones]

Okay. Didn't anticipate empty envvars. Try this:

import sys,os,nuke;get=os.environ.get;print 'sys.path:\n%s\n\nPYTHONPATH:\n%s\n\nNUKE_PATH:\n%s\n\nnuke.pluginPath:\n%s' % (sys.path,get('PYTHONPATH',None),get('NUKE_PATH',None),nuke.pluginPath())

[jjsa]

k. better ... here is the output import sys,os,nuke;get=os.environ.get;print 'sys.path:\n%s\n\nPYTHONPATH:\n%s\n\nNUKE_PATH:\n%s\n\nnuke.pluginPath:\n%s' % (sys.path,get('PYTHONPATH',None),get('NUKE_PATH',None),nuke.pluginPath())

Result: sys.path:

['/Users/admin/.nuke', '/Library/Application Support/Nuke/9.0/plugins/VRayDenoiser', '/Library/Application Support/Nuke/9.0/plugins/Cryptomatte', '/Applications/Nuke9.0v6/Nuke9.0v6.app/Contents/MacOS/plugins', '/Applications/Nuke9.0v6/Nuke9.0v6.app/Contents/MacOS/pythonextensions/site-packages/setuptools-0.6c11-py2.6.egg', '/Applications/Nuke9.0v6/Nuke9.0v6.app/Contents/MacOS/pythonextensions/site-packages/protobuf-2.5.0-py2.6.egg', '/Applications/Nuke9.0v6/Nuke9.0v6.app/Contents/MacOS/pythonextensions/site-packages', '', '/Applications/Nuke9.0v6/Nuke9.0v6.app/Contents/Frameworks/Python.framework/Versions/2.7/lib/python27.zip', '/Applications/Nuke9.0v6/Nuke9.0v6.app/Contents/Frameworks/Python.framework/Versions/2.7/lib/python2.7', '/Applications/Nuke9.0v6/Nuke9.0v6.app/Contents/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-darwin', '/Applications/Nuke9.0v6/Nuke9.0v6.app/Contents/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac', '/Applications/Nuke9.0v6/Nuke9.0v6.app/Contents/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac/lib-scriptpackages', '/Applications/Nuke9.0v6/Nuke9.0v6.app/Contents/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk', '/Applications/Nuke9.0v6/Nuke9.0v6.app/Contents/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-old', '/Applications/Nuke9.0v6/Nuke9.0v6.app/Contents/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload', '/Applications/Nuke9.0v6/Nuke9.0v6.app/Contents/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages', '/Library/Python/2.7/site-packages', '/Applications/Nuke9.0v6/Nuke9.0v6.app/Contents/MacOS/plugins/modules', '/Applications/Nuke9.0v6/Nuke9.0v6.app/Contents/MacOS/configs/Python/site-packages', '/Users/admin/.nuke/Python/site-packages']

PYTHONPATH: None

NUKE_PATH: /Library/Application Support/Nuke/9.0/plugins/VRayDenoiser:/Library/Application Support/Nuke/9.0/plugins/Cryptomatte

nuke.pluginPath: ['/Users/admin/.nuke', '/Library/Application Support/Nuke/9.0/plugins/VRayDenoiser', '/Library/Application Support/Nuke/9.0/plugins/Cryptomatte', '/Library/Application Support/Nuke/9.0/plugins', '/Applications/Nuke9.0v6/Nuke9.0v6.app/Contents/MacOS/plugins/user', '/Applications/Nuke9.0v6/Nuke9.0v6.app/Contents/MacOS/plugins/icons', '/Applications/Nuke9.0v6/Nuke9.0v6.app/Contents/MacOS/plugins']

[acjones]

Okay, so next thing would be to run the same script after launching in the way that's not working. I assume that means you'd need to disable Cryptomatte, but it will hopefully still help us understand what's different between the two launch methods.

[jjsa]

starting application for launchpad with Cryptomatte disabled to allow Nuke to start up

import sys,os,nuke;get=os.environ.get;print 'sys.path:\n%s\n\nPYTHONPATH:\n%s\n\nNUKE_PATH:\n%s\n\nnuke.pluginPath:\n%s' % (sys.path,get('PYTHONPATH',None),get('NUKE_PATH',None),nuke.pluginPath())

Result: sys.path:

['/Users/admin/.nuke', '/Applications/Nuke9.0v6/Nuke9.0v6.app/Contents/MacOS/plugins', '/Applications/Nuke9.0v6/Nuke9.0v6.app/Contents/MacOS/pythonextensions/site-packages/setuptools-0.6c11-py2.6.egg', '/Applications/Nuke9.0v6/Nuke9.0v6.app/Contents/MacOS/pythonextensions/site-packages/protobuf-2.5.0-py2.6.egg', '/Applications/Nuke9.0v6/Nuke9.0v6.app/Contents/MacOS/pythonextensions/site-packages', '', '/Applications/Nuke9.0v6/Nuke9.0v6.app/Contents/Frameworks/Python.framework/Versions/2.7/lib/python27.zip', '/Applications/Nuke9.0v6/Nuke9.0v6.app/Contents/Frameworks/Python.framework/Versions/2.7/lib/python2.7', '/Applications/Nuke9.0v6/Nuke9.0v6.app/Contents/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-darwin', '/Applications/Nuke9.0v6/Nuke9.0v6.app/Contents/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac', '/Applications/Nuke9.0v6/Nuke9.0v6.app/Contents/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac/lib-scriptpackages', '/Applications/Nuke9.0v6/Nuke9.0v6.app/Contents/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk', '/Applications/Nuke9.0v6/Nuke9.0v6.app/Contents/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-old', '/Applications/Nuke9.0v6/Nuke9.0v6.app/Contents/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload', '/Applications/Nuke9.0v6/Nuke9.0v6.app/Contents/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages', '/Library/Python/2.7/site-packages', '/Applications/Nuke9.0v6/Nuke9.0v6.app/Contents/MacOS/plugins/modules', '/Applications/Nuke9.0v6/Nuke9.0v6.app/Contents/MacOS/configs/Python/site-packages', '/Users/admin/.nuke/Python/site-packages']

PYTHONPATH: None

NUKE_PATH: None

nuke.pluginPath: ['/Users/admin/.nuke', '/Library/Application Support/Nuke/9.0/plugins', '/Library/Application Support/Nuke/9.0/plugins/VRayDenoiser', '/Applications/Nuke9.0v6/Nuke9.0v6.app/Contents/MacOS/plugins/user', '/Applications/Nuke9.0v6/Nuke9.0v6.app/Contents/MacOS/plugins/icons', '/Applications/Nuke9.0v6/Nuke9.0v6.app/Contents/MacOS/plugins']

[jjsa]

NUKE_PATH appears to be none even though its set as an environment variable for the current user

deadline007:~ admin$ printenv TERM_PROGRAM=Apple_Terminal SHELL=/bin/bash TERM=xterm-256color TMPDIR=/var/folders/1w/nyx5zn_n5qnfs49zwr0b63y80000gn/T/ Apple_PubSub_Socket_Render=/private/tmp/com.apple.launchd.0sYXUCtxbt/Render TERM_PROGRAM_VERSION=343.7 TERM_SESSION_ID=1A3B4920-F235-4511-9FBF-6D2E4742C141 USER=admin SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.pKKfejNl4U/Listeners __CF_USER_TEXT_ENCODING=0x1F5:0x0:0x0 PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin VRAY_FOR_MAYA2017_MAIN_x64=/Applications/Autodesk/maya2017/vray PWD=/Users/admin LANG=en_US.UTF-8 VRAY_FOR_MAYA2017_PLUGINS_PowerPC=/Applications/Autodesk/maya2017/vray/vrayplugins XPC_FLAGS=0x0 XPC_SERVICE_NAME=0 VRAY_PATH=:/Applications/Autodesk/maya2017/vray/bin SHLVL=1 HOME=/Users/admin LOGNAME=admin VRAY_TOOLS_MAYA2017_x64=/Applications/ChaosGroup/V-Ray/Maya2017/bin NUKE_PATH=/Library/Application Support/Nuke/9.0/plugins/VRayDenoiser:/Library/Application Support/Nuke/9.0/plugins/Cryptomatte VRAY_FOR_MAYA2017_MAIN_PowerPC=/Applications/Autodesk/maya2017/vray VRAY_FOR_MAYA2017_PLUGINSx64=/Applications/Autodesk/maya2017/vray/vrayplugins SECURITYSESSIONID=186a5 =/usr/bin/printenv

[jjsa]

just for fun ... i removed renamed init.py to init.py.save and then tried again ... now fails on menu.py but allows me to see details

Traceback (most recent call last): File "/Library/Application Support/Nuke/9.0/plugins/Cryptomatte/menu.py", line 8, in import cryptomatte_utilities ImportError: No module named cryptomatte_utilities

seems to not be able to find the file even though its in the directory of the plugin

deadline007:Cryptomatte admin$ pwd /Library/Application Support/Nuke/9.0/plugins/Cryptomatte deadline007:Cryptomatte admin$ ls Cryptomatte.gizmo cryptomatte_utilities.py init.py.save pymmh3.pyc Encryptomatte.gizmo cryptomatte_utilities.pyc menu.py cryptomatte_logo.png cryptomatte_utilities_tests.py pymmh3.py

[acjones]

Yeah, I think that's definitely the problem. So, the thing that actually matters in terms of Cryptomatte finding its python modules is the path returned by "sys.path" in python. That's Python's actual list of folders where it will search for modules.

It seems like NUKE_PATH is probably important for adding things to the python module search path. (The Nuke docs probably have more details on how that all works...)

How did you setup NUKE_PATH for the user? Did you add some lines to a file, or just define the variable in a shell? If so, which file?

(I'm going to assume this is the problem and provide some more info, but apologies if you're already a step ahead of me and all of this is irrelevant)

Depending on how you set an environment variable, it doesn't necessarily make it into every session for a particular user. In *nix OSes, there's a whole cascade of scripts that run to set all of that up, and for the most part unless a variable is defined in one of those files, it won't exist in new sessions. This article has some useful info on how to set this up on a Mac (and in particular, it seems to deal with making environment variables available to GUI apps):

Setting Environment Variables in OSX

Long story short is that in order to get the variables to work from Spotlight, you'd have to add a line like:

setenv NUKE_PATH /Library/Application Support/Nuke/9.0/plugins/VRayDenoiser:/Library/Application Support/Nuke/9.0/plugins/Cryptomatte

to the file /etc/launchd.conf, and then reboot.

Also BIG CAVEAT Please be careful. I haven't tested any of this, and editing files in /etc can really mess with a system. I don't see any reason to expect anything particularly scary to happen, but I feel a warning is obligatory if I'm telling someone to edit something in their config folder.

Sidebar: To be perfectly honest, I'm not a huge fan of doing plugin config at the system level anyway. If nothing else, it's just really difficult to maintain if you're dealing with multiple machines. But I'm speaking from the standpoint of working at a mostly-Windows studio with hundreds of computers, and of course everyone's situation is different. And I can certainly see where getting things launching through Spotlight is desirable.

Anyway, let us know how it goes with this if you decide to proceed with launchd.conf. Although the nitty-gritty of NUKE_PATH on OSX is a bit out of scope for Cryptomatte, if this turns out to be the problem, I'd rather put some mention of it in our installation instructions than have other people run into the same issue.

[AndrewHazelden]

Hi.

Is there a chance you need to set the $NUKE_PATH environment variable using a .plist entry in your /Library/LaunchAgents/ folder for it to be active when you start Nuke from the Apple LaunchPad interface?

I’ve seen strange things like this happen with some other VFX tools on MacOS 10.12 before. In those cases the programs didn’t have access to environment variables defined in the .bash_profile or .profile documents unless the program was started from a Terminal.app session.

This is an untested example file that shows the rough idea of what you might add to a plain text formatted launch agent entry with a name like /Library/LaunchAgents/setenv.foundry.NUKE_PATH.plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
    <dict>
        <key>Label</key>
        <string>setenv.foundry.NUKE_PATH</string>
        <key>ProgramArguments</key>
        <array>
            <string>/bin/launchctl</string>
            <string>setenv</string>
            <string>NUKE_PATH</string>
            <string>/Library/Application Support/Nuke/9.0/plugins/VRayDenoiser:/Library/Application Support/Nuke/9.0/plugins/Cryptomatte</string>
        </array>
        <key>RunAtLoad</key>
        <true/>
    </dict>
</plist>

You would also have to change the launch agent .plist file ownership so the file is loaded automatically during the startup phase:

sudo chown root /Library/LaunchAgents/setenv.foundry.NUKE_PATH.plist
sudo chgrp wheel /Library/LaunchAgents/setenv.foundry.NUKE_PATH.plist

I noticed you have V-Ray installed on your system. If you look in the Launch Agents folder you can see the V-Ray centric .plist files there. Chaos Group configures their environment variables using the exact same kind of approach I have pointed to in this message.

Regards, Andrew Hazelden

[jjsa]

ac ... i tried to set it in the launchd.conf but that didn't change the behavior

andrew ... good idea ... let me try to your suggestion

[jjsa]

btw ... i set the NUKE_PATH in /etc/profile to make sure all users get it

[jjsa]

i think the plist worked (forgot i had to restart launchd or reboot system) to have it take effect ... need to try it on another machine to see if i can replicate the solution

[jjsa]

i was able to confirm on another system ... looks good. thanks again ac and andrew for the help

[acjones]

Awesome. So, what was the final answer? Plist or launchd.conf? Or did you end up getting /etc/profile working? (I want to put some kind of small note about this in our installation instructions, but I don't have easy access to a Mac to test). Also, Andrew, feel free to chime in if you have thoughts on what that note should say. Sounds like "You must reboot for changes to take effect" should be part of it. I'm guessing Chaos Group probably chose to use a plist for a reason...

[AndrewHazelden]

Hi Andy.

I'm guessing Chaos Group probably chose to use a plist for a reason...

As far as documentation notes go, each .plist file is isolated and can be validated by the system at boot time for the correct syntax so it avoids formatting issues that could crop up with other approaches.

I can see there being lots of room for disaster if you tried to get a new user who was unfamiliar with the terminal to try and modify a larger conf text file with multiple pre-existing entries in it using vim/nano/pico/etc...

The LaunchControl.app utility can be handy if someone wanted a visual way to open and edit a Launch Agent centric .plist file and be able to to test it without restarting:

http://www.soma-zone.com/LaunchControl/

---

As an additional tip, the default text editor program that comes with macOS is called TextEdit.app. It will often default to saving out an .rtf format document. This can be a source of headaches for troubleshooting issues when someone saves a new document to disk using the program.

Combine that .rtf output with a user having the Finder preference option "Show all filename extensions" turned off and you can't easily guess what filetype was saved to disk without more back and forth questions.

[jonahfriedman]

Cool, thanks everyone. Add this to the list of things to possibly document.