Farm_wrapper and Nuke

Pipeline Integrations
1

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
2

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

1 Like
3

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
4

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.

5

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.

6

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?

7

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

8

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!

11

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
12

Thanks I’ll do that.

14

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?

15

Hey Phil,
Bringing this one back from the dead after almost a year!
I’ve come across similar issues with another client.
Here I have two plugins adding to the item custom gui.

  1. Settings widgets for an alembic export plugin.
  2. The farm wrapper.

If my publish2 yml has the order farmwrapper:alembicexport, then I end up with a tab widget with a tab for each plugins settings… which is what I want. The problem is that the settings setter is only firing for the farmwrapper… so my alembicexport default settings are not being set.
If I switch the order the plugins are loaded, then the alembicexport settings get set, but the farmwrapper is added to a tab widget IN the alembicexport settings widget.

It seems like the tabwidget should be a standard container in the publisher settings layout to allow a tab for each plugins settings?

Currently, it seems it’s not possible to have settings for more than one plugin on a single publish item. If that’s not the case, could you post a code example that shows how two plugins can add a settings tab and still have a working getter/setter?

1 Like
16

Het Patrick!

I just wanted to clarify what you mean here, we don’t support custom GUI’s on the item, only on the plugin. So are you saying that your item has two plugins and that they each have a custom GUI that displays when you select the respective plugin?

It’s probably my brain just not waking up yet, but is this a hook inheritance order or the order of two separate plugins?
The : normally indicates hook inheritance hierarchy, so is this one plugin that is formed by a couple of plugin hooks using inheritance hierarchy?

In short, I’m just trying to better wrap my head around the setup.

17

I’m not sure what you mean by only supporting custom GUI’s on the item.
We have a custom plugin that presents alembic exporting properties. This has a custom GUI.
We also have the farm_wrapper implemented as in this thread. This means we can export/publish alembics locally, and if necessary on the farm.
Are you saying that if you use the farm_wrapper, that you can’t implement a plugin that uses a custom gui alongside it?

You are correct about the hook inheritance order.
It’s as you’ve described in this thread; eg publish_file.py:farm_wrapper.py, except we’ve replaced the publish_file.py plugin with our own custom alembic export/publish plugin.

Thanks!

18

What I meant by custom GUI on the item, is that if you select an item in the publish tree, you can’t customize the panel you see on the right. You can only customize it when selecting a plugin.
But yeah sounds like you are customizing the plugin GUI, not the item GUI. I should have really assumed that, I don’t think I was awake properly the other day.

OK so I think I understand whats going on here. My question would be, are you calling super in your farm wrapper setter method to get the result from the base alembic plugin method?

19

Yes I am, I’ve just used the code from your Farm Wrapper examples.

1 Like
20

OK thanks for confirming. I will need to take a deeper look and try it out, but I’m not sure when I’ll have the time at the moment. I don’t know off the top of my head why this wouldn’t work.

21

Actually, I misread your question. I’m not calling super on the setter method.
Can we move back to my ticket (#117888)? I’ve uploaded our publisher hooks and settings for you to take a look.
Thanks again.
p.

22

Just bouncing this in the hope of a response :slight_smile:
Thanks.
p.

24

Hey, I’m sorry I’ve not had the time this last week.

I’ve just taken a look now, and in the current state of the files you sent, it looks like it is setup to be alembicexport:farmwrapper.

I’ve taken a look at both plugins, and as you said the set_ui_settings() and get_ui_settings() are not calling super in the farm wrapper, so that it runs the alembicexport respective methods. If you want to base classes to run their implementations you will need to call super.

Phil