Added support for Nuke tree serialization

[reformstudios]

When publishing using farm_wrapper and serializing the publish tree in Nuke, the presence of a nuke node (eg the writenode) causes the tree.save method to error. Whilst this may be pointing to another greater bug in the code ( super(_PublishTreeEncoder).default(data) errors saying the parent class has no attribute default) a workaround is to gracefully handle writenodes before the default return is called.

This workaround checks that we're in a nuke environment before importing nuke and checking the data is an instance of a nuke.Gizmo. IF it is a gizmo, we serialise the name of the node.

Feature Request

It will probably be necessary to catch other publish types in this code, and if so, perhaps it should be exposed as a hook so studios won't need to fork this code to define how custom items are serialized.

[coveralls]

Coverage decreased (-0.2%) to 69.477% when pulling 0e76901 on reformstudios:patch-3 into 6156977 on shotgunsoftware:master.

[pscadding]

Hey Patrick, thanks for this, we've got a PR for this already and it's in testing:#112
I'll close this out, but thanks again for taking the time to submit it!

[pscadding]

Sorry, my apologies I missed that this was doing something more than fixing the bug. I've reopened it!

[pscadding]

Just looking at the suggested addition, my thoughts are that, whilst that could allow the write node to be serialized to an extent, it wouldn't allow it to be reverted to the actual node when unserialized.
I think the aim of serialization is to end up with the same at the end as you put in at the beginning.

[reformstudios]

I think the problem is the default nuke publish is gathering the nuke writenodes rather than the templates.

…

On Thu, 5 Dec 2019 at 18:00, Philip Scadding ***@***.***> wrote: Just looking at the suggested addition, my thoughts are that, whilst that could allow the write node to be serialized to an extent, it wouldn't allow it to be reverted to the actual node when unserialized. I think the aim of serialization is to end up with the same at the end as you put in at the beginning. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#113?email_source=notifications&email_token=ABD4XQAFYBCGBYQEQWYB4YLQXE6R7A5CNFSM4JV4GWK2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGBSL7A#issuecomment-562243068>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABD4XQAQZO6E6TRHRSR4TQDQXE6R7ANCNFSM4JV4GWKQ> .

[pscadding]

Yeah, that's a fair point, I think it would probably be true to say the hook was written before the save method was added, so serialization wasn't considered when it was written. Perhaps the fix would be to adjust our collector and plugin instead.

[reformstudios]

Yup definitely... shall I leave it to you to raise the pull request?
I do wonder if there might be circumstances where a publish tree might need to have items that aren't simply file templates. Or maybe the items do need to point to nodes (eg for doing renders or exports). In which case my point still stands, we need to be able to serialise items of unknown type, so we need a hook. Or
I guess the farm_wrapper is loading the scene, so the publisher only needs to be able to find scene objects via this serialised data, so a node GUID or name should work, so maybe reconfiguring the collector would work?

[pscadding]

hey sorry for the delay, I'm going to log an internal bug ticket for the Nuke publish plugins not handling serialization on the write nodes.
In a more general sense though I think the approach is supposed to be that you serialize stuff before adding it as a property on an item.