Bugfix/201 fix some typo and correct expected return types

[MustafaJafar]

Changelog Description

resolve #201

Note:
get_invalid should return None or list of hou.Node/ hou.OpNode

Testing notes:

1. Error reported in the linked issue should be fixed
2. Everything should work as before

[moonyuet]

ValidateSingleFrame has been errored out

Uploading publish-report-241224-17-57.json…

[moonyuet]

Looks good now!

[BigRoy]

I wonder if it makes sense to let our IDEs help us out a hand in the future - and add Type Hints to the get_invalid methods so it's hinted to be Optional[List["hou.Node"]]?

[MustafaJafar]

I wonder if it makes sense to let our IDEs help us out a hand in the future - and add Type Hints to the get_invalid methods so it's hinted to be Optional[List["hou.Node"]]?

This will be cool!
Note:
It's expected that get_invalid returns Optional[List["hou.Node"]] only when we are using select invalid action.

[BigRoy]

Overall the change looks good - but in most cases you're not refactoring how we're formatting the node into the PublishValidationError which means the message there will turn out worse. So we may want to make sure there that we're still formatting using the path of the nodes.

[BigRoy]

Note: It's expected that get_invalid returns Optional[List["hou.Node"]] only when we are using select invalid action.

Yup, am aware - but I have a feeling that should be 99% of the use cases of the get_invalid class methods or static methods. (And I'd rather have it for all of them to avoid confusion if suddenly one does not behave that way.) And if there's indeed a reason for one of them to deviate, hopefully seeing the type hints differ there will also help make sense of things.

[MustafaJafar]

Note: It's expected that get_invalid returns Optional[List["hou.Node"]] only when we are using select invalid action.

Yup, am aware - but I have a feeling that should be 99% of the use cases of the get_invalid class methods or static methods. (And I'd rather have it for all of them to avoid confusion if suddenly one does not behave that way.) And if there's indeed a reason for one of them to deviate, hopefully seeing the type hints differ there will also help make sense of things.

what about implementing get_invalid on HoudiniInstancePlugin and HoudiniContextPlugin.
most of the time,
get_invalid on context plugins is most of the times: get_invalid(cls, context)
get_invalid on instance plugins is most of the times: get_invalid(cls, instance)

[moonyuet]

Tested with publishing the model product types in Houdini. Validators looks good for me.

[moonyuet]

One thing is a worth mention that somehow validate resolution setting does not validate the resolution correctly in my case. Even if I set the resolution back to 1920X1080, the validator still blocks me from publishing the render (Do it in separate PR as it's not related to this PR)

[MustafaJafar]

One thing is a worth mention that somehow validate resolution setting does not validate the resolution correctly in my case. Even if I set the resolution back to 1920X1080, the validator still blocks me from publishing the render (Do it in separate PR as it's not related to this PR)

This is weird, I was not able to replicate it on my side.
could you create an issue with reproducible steps ?