Farm_wrapper and Nuke

I’m encountering some issues with the farm_wrapper(webinar) and Nuke.

I’ve got the publish working ok, but using the wrapper causes the submit_for_review method to fail.

It’s expecting publish data to exist, but as there isn’t any created on farm_wrapper items, it fails.

Can your farm_wrapper guru take a look and suggest a fix for this?

I imagine the submit_for_review method needs to query the item for the farm_wrapper properties and then only attempt to execute the task if it’s a farm_wrapper job and it’s not running locally… I’ve had a go at doing this myself but have come up short!

Thanks for any help
p.

3 Likes

Hey Patrick I’ll check in with the team and get back to you.
Cheers
Phil

1 Like

Hi Patrick,

“Guru” here. :smile: It’s been a while since I dabbled in the code I wrote for the webinar. You’re saying the task that published the item is executed on the farm. Would executing the submit_for_review task on the farm as well make sense? If the item hasn’t been published yet, then there is nothing to render and submit for review, so it seems like that task should run on the farm as well. To get this behaviour, you can add farm_wrapper in the inheritance chain for the submit for review plugin just like you did for your other publish plugin.

Am I missing anything?

Cheers,

JF

2 Likes

Hi Jean, and thanks for the webinar and code, much appreciated!

Yup, that’s what I ended up doing. That works if I default all farm_wrapper items to be enabled, but if the client doesn’t want this enabled by default, then it means if a user forgets to enable the farm_wrapper on both items, then the submit_for_review will fail. Is there any way to link that item to its parent in some way to avoid this condition arising?

One other question, I’m not getting the usual logging from the publisher when it’s being run from the publish_manager. How would I get the publisher to show it’s logs when run on the farm? At the moment I only get the print statements.

Hi again!

If there was a way from the GUI to access the item, you could toggle the farm submission flag on the item for all tasks instead of doing it at the task level. Unfortunately we didn’t consider that scenario when we wrote the create/set/get methods for the GUI update method and we’re only passing in the settings of the task and not the item associated to it like we do for other methods. :man_facepalming:

I’m afraid that right now there is no clean way to do this. Fortunately, we can always hack something with Python, right? :smile:

Let me preface this that I haven’t tried this personally, so I might get some of the details wrong.

When the FarmWrapper plugin’s accept method get’s called, the settings and items are passed in. Maybe you could update a dictionary inside your plugin that maps settings to items, so this way you have a reference back to the item associated with the settings. Don’t forget to call the base class at the same time. :slight_smile:

Then inside the GUI code, you will be able to resolve the item associated with the settings and toggle the flag at the item level, modifying the flag for all tasks under the item.

You’ll also need to update the logic inside render_node.py and FarmWrapper._is_submitting_to_farm to check for the Submit to Farm flag on the item instead of on the task.

Finally, since the render_node.py, script won’t be able to tell if a particular task is using the FarmWrapper, so you’ll need to store a hint in the settings of those task that basically says “If I’m present, then check if the item has the farm toggle set”.

For the logging, I’m assuming that you are talking about the logging you usually get in the GUI, is that it? Yeah, unfortunately it seems like this logging does not get logger in the Toolkit logs. Once again, :man_facepalming: .

EDIT: Oh actually, there might be a solution to that logger problem. The publish manager object has a logger property. You could add a handler on it that simply routes logs back to the sgtk.LogManager().root_logger. The output might be a bit messy tough.

Let us know if this works!

JF

PS: I’m in no way recommending that this becomes the official way to do this. We’ll see if we can make this more simple in a future release of the publish app.

Thanks for the suggestions. I might wait till you have a chance to test before I dig in to it!
I’ll try what you suggest about the logger.

Is it just me, or does the @state.setter method in the FarmWrapperWidget, not work?
I can set the checkbox default value, but when I click the checkbox, the box is checked, but the print statement in my @state.setter isn’t printing anything out, and the state isn’t respected when submitting the publish, so I wonder if the setter isn’t being called for some reason? Could it be because of the update you posted that puts the checkbox in a tab?

Unfortunately, I do not have time to test and debug my suggestion right now, as I’m deep into the Python 3 rabbit hole.

I think I may have hinted during the webinar at adding the checkbox in the tab so you can keep the original UI of the plugin in a separate one, but I have not implemented it. The @state.setter is called by the set_ui_settings method, not by the GUI itself. The @property on FarmWrapperWidget is simply a wrapper around the checkbox and is accessed by the plugin’s get_ui_settings/set_ui_settings methods.

Cheers,

JF

Yup that’s the code I implimented.
I think my problem is that the set_ui_settings widget is pointing to the tabWidget, not the checkbox… but changing widget.state to widget._check_box.state raises an error : PySide2.QtWidgets.QTabWidget' object has no attribute '_check_box'

How would I update the set_ui_settings to point to the check_box widget rather than the tab_widget?

Apologies for my Qt confusions!

Hi again!
I suspect there might be something wrong with your plugin’s code, but in case there’s a bug on our end, I think a support ticket would probably be the best place to resolve this issue. Would you mind submitting one with a copy of your hook so we can take a look?
Thanks!
JF

1 Like

Thanks I’ll do that.

Hey Patrick

I took a look at your code and I think I can see the problem.
You’re creating a tab widget and then adding the default widget and the wrapper widget as sub widgets, which is fine. The problem occurs when you try to set the widget’s state.

You have widget.state = settings[self._SUBMIT_TO_FARM], where widget is equal to the tab widget and not the sub farm wrapper widget.
You’re a bit unfortunate, as it’s not throwing an error, because it is essentially patching the QTabWidget class to have a state attribute, rather than calling the state getter and setter on the sub widget.
So maybe you could either turn the farm wrapper widget into handling both the tab widget and the sub widget or have something like tab_widget.wrapper_widget = wrapper_widget in the widget creation method and then call it like widget.wrapper_widget.state = settings[self._SUBMIT_TO_FARM] in the set settings method.

Does that make sense?