Am I right in discovering that it’s not possible to execute a publish from a non gui dcc session?
I tried via Nuke, and when I attempt “manager.collect_session()” as per the docs on https://developer.shotgridsoftware.com/tk-multi-publish2/api.html, it crashes right out of Nuke.
Error : “line 1: 1358 Aborted (core dumped)”
I thought the purpose of the publishManager api was to allow scripted publishing?
If it isn’t possible, is it on the roadmap to get it implemented?
Thanks
p.
Hello Patrick. It’s certainly possible, although I never tried with Nuke. Usually, it’s just a matter of bootstrapping the toolkit and then running the collector.
It should be possible to collect more information about the crash, add try/catches around the place that fails. Also use the faulthandler module to report uncaught fatal errors.
Might be either importing Qt or trying to use Qt. afaik core tries to determine whether the session is graphical and only then loads Qt, but don’t know the details of it.
Edit: as vtrvtr said, you have to bootstrap core yourself, so sgtk.platform.current_engine() won’t work if there’s no engine running.
Thanks for the suggestions guys.
I made some progress. The first improvement is using nuke --tg to launch nuke as a QApplication.
The next issue was that opening the nukescript only launched in to a “shot” environment, not shot-step. So I added the necessary writenode and publish settings to my shot environment.
My problem now is that the tk-writenode isn’t working. When I load the scene, the writenode is being loaded as a placeholder and not converted in to a sg writenode.
I’ve installed PySide2 on the workstation so everything should be in place.
My next test will be to try to load the scene using workfiles2 rather than the standard nuke openscript command.
Thanks again.
p.
Aha!
I figured out the issue.
For the writenodes to load properly, I need to first do :-
ctx = tk.context_from_path(nukescript_path)
engine.change_context(ctx)
nuke.scriptOpen(nukescript_path)
With the scene opened in to the correct context, the publisher is now working.
I wonder why the writenode callbacks are failing to automatically context change on open?
I’ve got to bring this thread back from the dead…
It looks like I need to launch nuke with -t not --tg as when the script is run on the farm, there is no x-system on the headless sessions…
So, the error I’m getting when running “manager.collect_session()” is
QPlatformPixmap: QGuiApplication required
So, although the publisher is supposed to work without a gui, it seems that some part of it is still erroring when I’m in a headless session. I can’t find any reference to this error message in shotgun code, and the fact it causes nuke to hard-exit, suggests it might be a call to something outside SG that’s causing the issue.
Can anyone help me figure out how to get the publish_manager working in a headless environment?
Thanks again
p.
In a Nuke shell session, I am able to import PySide2, and it shows as a Nuke python extension and version 5.12.2, if that helps understand the issue better.
<module 'PySide2' from '/mnt/prod/software/linux/Nuke12.2v6/pythonextensions/site-packages/PySide2/__init__.pyc'>
I’m using Nuke 12.2v6.
I am also able to execute the publish2 api item _is_qt_pixmap_usable() code :
from sgtk.platform.qt import QtGui
QtGui.QPixmap
QtGui.QApplication.instance()
Without errors or crashing.
The line QtGui.QPixmap(path) DOES crash nuke though… interesting.
Copied from my support ticket here for visibility : -
On further investigation, the problem is due to this line :
QtGui.QPixmap(file)
In Nuke 12.2v6 this is crashing Nuke.
To test, you can start a SG Nuke shell environment (add “-t” to the software entity args so you can launch directly in to a shell. I’m using the following linux path in my software entity : “gnome-terminal -t “Nuke 12.2v7” – /apps/foundry/nuke/Nuke12.2v7/Nuke12.2 -t”
Once in a shell, if you run the following, the nuke session will crash.
"
from sgtk.platform.qt import QtGui
path=""
QtGui.QPixmap(path)
"
Running the same code in a GUI session of nuke does not crash Nuke.
This is replicating the logic found in : tk-multi-publish2/item.py at master · shotgunsoftware/tk-multi-publish2 · GitHub _validate_image() method.
So, the first thing this method does is to check if qt pixmap is available.
In the _validate_image() method, you’ve wrapped some code in a try/except to attempt to get QtGui.QPixmap to return an icon. It looks like even in a try/except, the calls you are doing are causing Nuke to crash out with a hard exit.
What it does is first attempt to get QtGui from sgtk.platform.qt:
from sgtk.platform.qt import QtGui
Then it gets the object
QtGui.QPixmap
In my shell environment, this is successful, so the exception is skipped.
The code then goes on to the “else” section… where it first checks for a QApplication instance with
QtGui.QApplication.instance()
In my session this returns the instance.
So, this method returns True for _qt_pixmap_is_usable.
So, back to _validate_image() method. We get QtGui again,
from sgtk.platform.qt import QtGui
Then attempt in a try/except to get the icon:
icon = QtGui.QPixmap(path)
It’s this line that crashes nuke out.
Assuming the init method might be the problem, I tested creating an empty pixmap. This works, but when I try to load in the image, it crashes nuke again.
QtGui.QPixmap().load(path)
This is all in a centos7 environment.
Doing “pip list” shows PySide 1.2.4 installed in my environment.
I’ve tested on Nuke11.3v3, 12.2v6 and 12.2v7.
I guess this is a Qt bug, but for shell publishing, this problem should be caught in the publisher code.
Any suggestions on how to fix this?
Bump.
Hello,
Exactly the same problem here in Nuke. Was this problem ever solved?
As a side note, it works perfectly in Maya.
Edit:
So far, I was able to do the publish by commenting all codes that set an icon or a thumbnail.
But this so annoying because I’ve published images with no thumbnails.