Can't get shotgun toolkit to work with nuke studio, config_default2

Pipeline Integrations
1

Okay so this is going to be a bit of a tough one to debug but here goes nothing…

I have nuke_studio fully working with the old style config, but after updating to config_default2 it does not even initialize. Under Nuke 12.0 studio I get no errors in the script editor, but in Nuke 11.1v3 I get:

ERROR 18:13:28.365:Hiero(34236): Error! Task type tk_hiero_export.sg_shot_processor.ShotgunShotProcessor Not recognised

I have rolled all my apps back to the shotgun stable releases, I have updated the core, and all the apps and engines to the latest… so in my mind there should be no errors, but without fail it still does not initialize the tk-nuke engine, and shotgun fails to load anything…

I have attached a full log, this is in a testing environment, so no worries with NDAs…

I am using
name: tk-nuke
version: v0.12.5

name: tk-hiero-openinshotgun
version: v0.3.4

name: tk-hiero-export
version: v0.5.3

all on core version:
v0.18.172

tk-nuke.log (16.1 KB)

Please help,
-Ross

2 Likes
2

Have you tried with an unaltered default2 config? Does it work if you take the latest release of the config?

When you say Nuke 11.1v3, do you mean Nuke Studio 11.1.v3?

1 Like
3

Hey Philip,
Okay, So i made a clean config where I forked that tk-config-default2 so I am using a completely clean config, I even switched my software paths to point to:
C:\Program Files\Nuke12.0v2\Nuke12.0.exe -studio
and
C:\Program Files\Nuke11.1v4\Nuke11.1.exe -studio
I am still getting the exact same error… under 11.1 and no errors in the script editor for 12.0 but shotgun doesn’t initialize anything;

11.1 error: tk_hiero_export.sg_shot_processor.ShotgunShotProcessor Not recognised

if I run:

import sgtk

print sgtk.platform.current_engine()

# Result: None

so shotgun is initialized, but the engine isn’t getting loaded but I can’t seem to find the error of why it doesn’t load.

I have attached another log
tk-nuke.log (15.8 KB)

inside the log i do see a pyqt error:
2020-01-14 10:56:07,711 [9196 DEBUG sgtk.env.project.tk-nuke] Nuke 11+ on Windows can deadlock if QtWebEngineWidgets is imported. Setting SHOTGUN_SKIP_QTWEBENGINEWIDGETS_IMPORT=1…
2020-01-14 10:56:07,711 [9196 DEBUG sgtk.core.util.qt_importer] Requesting Qt4-like interface
2020-01-14 10:56:07,713 [9196 DEBUG sgtk.core.util.qt_importer] Unable to import module ‘QtWebKit’: No module named QtWebKitWidgets
2020-01-14 10:56:07,713 [9196 DEBUG sgtk.core.util.qt_importer] Imported PySide2 as PySide.
2020-01-14 10:56:07,713 [9196 DEBUG sgtk.core.util.qt_importer] Requesting Qt5-like interface
2020-01-14 10:56:07,739 [9196 DEBUG sgtk.core.util.qt_importer] Imported PySide2.

is that the issue?

for clarification this issue is only with nuke studio, regular nuke, and nukeX function perfectly under the new config, with all our custom pipeline stuff hooked up. I am ONLY experiencing issues with Nuke Studio 11.1v4 and 12.0v2 (basically all supported Nuke Studios)

-Ross

2 Likes
4

Hey Ross, thanks for trying that! So it likely rules out the configuration as the cause.

You shouldn’t need to set the software paths if you installed them in the default location, but I guess you tested both with and without?

As you say it seems it is not starting the engine. The 11.1 error: tk_hiero_export.sg_shot_processor.ShotgunShotProcessor Not recognised error is probably because the NS project has the preset baked into it, but it can’t load it since the integration wasn’t started.

The log you attached is named tk-nuke.log. Assuming you didn’t rename it from tk-nukestudio.log, then that log would only contain the standard Nuke output, and not NS. Do you have a tk-nukestudio.log file? It’s possible depending on where it is failing in the launch process, that it’s not even getting around to initializing the log, so you may not have one.

The log lines you highlighted look OK.

I would next turn my attention to the environment variables. Launch Nuke Studio from Shotgun again, and then print out the HIERO_PLUGIN_PATH variable in the script editor.

import os
print os.environ["HIERO_PLUGIN_PATH"]

And see what that gives you.

1 Like
5

Hey,
I mentioned that I was using the default paths, because we generally launch using a .py launcher that sets all our studio environment variables, and global paths to load plugins/gizmos ect for nuke, but I am bypassing that for these tests, because it does add environment variables that could clash (though they are tested under the other config with no issues), but to eliminate that as a problem and keep these tests clean, I am circumventing all of that and doing a clean launch using the system installed path.

Okay, So I do notice that I don’t have a nukestudio.log;
as a side note, under our stable released config I do get a nukestudio.log so it is definitely failing before it even gets there.

also that environment variable:
import os
print os.environ[“HIERO_PLUGIN_PATH”]

returns:
KeyError: 'HIERO_PLUGIN_PATH"

so it’s not getting properly filled at all. I know under the old config this used to have information for sure.

Have you tested the config_default2 latest release with nuke studio? I think there is definitely something not setup correctly with the environment variables with this new config?

1 Like
6

Hey Ross,

We’ve tested it on Window 10 with Nuke 12 and with the latest config, but we are not seeing any issues.

The fact that the env var is not set is likely the key to this. Without that being set the startup script will not be run. Out of curiosity is TANK_CONTEXT or TANK_ENGINE set?

My next step would be to take over tk-multi-launchapp's app_launch.py hook, and add a log line in there before the application is launched to log out the HIERO_PLUGIN_PATH env var.

import os
self.logger.info("HIERO_PLUGIN_PATH: %s" % os.environ["HIERO_PLUGIN_PATH"])

If it is set there and it is not set once the application is launched, then something is happening to it in between, that is likely out of Shotgun’s scope.

Cheers
Phil

1 Like
7

Hey philip,
So I added that logger check… and I get a key error there as well :(…
so where does toolkit set that “HIERO_PLUGIN_PATH” ? is there a way for me to see where that env var is supposed to be set, and what it is supposed to be set with? That new config doesn’t seem to be correctly setting it for nuke_studio?

here is the console desktop output log showing the result from adding that logger “HIERO_PLUGIN_PATH”

https://drive.google.com/open?id=1stF3oG_MknHeQYetvMYRr4XmI69sFCus

I also ran “TANK_CONTEXT” and “TANK_ENGINE” no errors, and a seemingly valid output?

result of “TANK_CONTEXT”
https://drive.google.com/open?id=1XJu8KUSD9VjLBcQjf5oxZ2h2k9j5AklV

import os
print os.environ["TANK_CONTEXT"]
# Result: (dp0
S'additional_entities'
p1
(lp2
sS'source_entity'
p3
(dp4
S'name'
p5
S'pipeline_ppl-0000'
p6
sS'image'
p7
S'https://sg-media-usor-01.s3-accelerate.amazonaws.com/...
p8
sS'id'
p9
I77
sS'current_user_favorite'
p10
I00
sS'last_accessed_by_current_user'
p11
F1579230078.0
sS'type'
p12
S'Project'
p13
sS'sg_status'
p14
S'Active'
p15
sS'sg_description'
p16
NssS'task'
p17
NsS'_pc_path'
p18
S'S:\\software\\shotgun\\dffx\\pipeline_ppl-0000_sg_config-default2'
p19
sS'entity'
p20
NsS'project'
p21
(dp22
S'type'
p23
g13
sS'id'
p24
I77
sS'name'
p25
g6
ssS'_current_user'
p26
S"(dp1\nS'data'..."
p27
sS'step'
p28
NsS'user'
p29
(dp30
g23
S'HumanUser'
p31
sg24
I54
sg25
S'Ross Macaluso'
p32
ss.

result of “TANK_ENGINE”
https://drive.google.com/open?id=1L2jaa-8G92hxwE2FE4akUaRp6zLI-q7R

import os
print os.environ["TANK_ENGINE"]
# Result: tk-nuke

Thanks for helping me with this,
Ross

2 Likes
8

Ah very interesting, thanks for that. OK so that suggests that it’s not treating it as a NukeStudio launch, and is probably instead treating it as a standard Nuke launch.

I just took a look at your site, and I can see that you’ve defined a Nuke Studio Software entity, with a path, and set the args to -studio. But I think the arg needs to be --studio. I’m hoping that is the issue. :crossed_fingers:

Edit, to include more information in the answer: @Ross_Macaluso also found that the engine value was set incorrectly: Can't get shotgun toolkit to work with nuke studio, config_default2

3 Likes
9

Oh… wow… thats really weird because it still launches studio and nukeX i would think if the windows argument was wrong it wouldnt launch the correct piece of software… why is it still launching the right software, but then shotgun isnt initalized? But you are totally correct changing it to --studio seems to now initalize the engine as well… this is really weird…
Ill keep poking around make sure all the apps and our custom stuff works, but yeah seems I just missed a “-” …
Thanks for helping!!

Ross

2 Likes
10

I wonder if Nuke allows for both --studio and -studio but Shotgun doesn’t. I think we are specifically checking for the --studio arg. So maybe that that is bug/polish ticket for us.
I’ll make a note to look at it on Monday.

I’m glad it is working for you now though!!

2 Likes
11

Ya the foundry allows both definitely, and I am more used to using just 1 “-” when doing command prompt arguments so that’s why I defaulted to that syntax…looking back at our old config I should have noticed that there I was using the “–” notation that you mentioned Shotgun requires… silly me… haha…
Thanks for catching, and sorting this for me,
-Ross

2 Likes
12

Hey Ross, Just to let you know, I’ve ticketed up the --studio vs -studio issue. Thanks for highlighting the other use was valid.

1 Like
13

Sweet thanks Philip,
It definitely seems like a small thing, but somehow it took me so long to realize that was the issue… haha… Mainly because I didn’t even think of checking the argument, since Nuke Studio was indeed launching lol…

P.S After fixing that argument I was still not getting into a tk-nukestudio environment, was still stuck in tk-nuke, Project… I realized that my engine was set to tk-nuke on the new software entity page… changing that to tk-nukestudio fixed it all up… Stupid silly mistakes…

-Ross

2 Likes