Show publish plug-in attributes based on families instead of only productType

[BigRoy]

Changelog Description

Show publish plug-in attributes based on families instead of only productType

This PR can be tested together with ynput/ayon-houdini#144

This PR split off from this one #973 so it only contains the tiny change.

Additional info

This commit 8208bef allows to show publish plugin attributes also based on the created instance families data instead of only the product type. As such, if the Creator defines extra families - then the Pyblish plug-ins for which it will run will now also show their publisher attributes.

This is a required change to easily start supporting a workflow where we can target particular instances from plug-ins without having to target the product type itself. This opens the door to allow say, five different creators, to each produce a model family but with e.g. a different representation - like a USD model, groom, look, etc.

📔 ✏️ Houdini (and Maya) currently exposes a get_publish_families method on the Creators - we may want to move that to the base creator plug-in in core by default because it'll greatly simplify the implementation of defining more families than just the product type from a creator across all the DCCs.

Why?

1. Product type versus families

Also see explanation on product type versus families.

The idea is that a product type should not be 1:1 tightly coupled to a particular node or export method inside the DCC, so that technically any amount of export methods could publish a product type like model or pointcache which only consider the product type's validations (like a model must be static) but not care at all about e.g. Alembic properties being set up correctly on the Alembic ROP.

Imagine an instance with families

• pointcache
• extractor.AbcExport

And an instance:

• model
• extractor.AbcExport

The intent is very clear - these instances have different product types but use the same means of exporting, triggering an Alembic exporter. It now becomes very easy to preserve the model logic for validations but just add a different means of extraction, like extractor.fbx, extractor.maya_usd or extractor.multiverse_usd, etc.

It should be much easier to without conflict add many creators with the same product type while avoiding 'collisions' on how to trigger only the relevant exporters or plug-ins.

Vice versa as well, it should be easy to add a file format (representation) to any amount of existing creators without needing to target model or pointcache.

Also, Explicit is better than Implicit.

2. Type hints and autocomplete for instances. (Less unknown dicts!)

Type Hinting: Preferably we can get to a point where if a certain family applies we can be sure certain data is present. For example:

from typing import TypedDict

class FrameRangeData(TypedDict):
    frameStart: int
    frameEnd: int
    handleStart: int
    handleEnd: int

class FrameRangeInstance:
    data: FrameRangeData

if is_family(instance, "framerange"):
    instance: FrameRangeInstance

Take this random example above.
My IDE now autocompletes for me:

And type hints:

3. Ensured data types (continuation of typed instances)

This could even be taken a step further to also be used for validation - using e.g. pydantic. If an instance says it has a frame range using a family - then we can even apply a dedicated validation plug-in validating whether the instance adheres to the type hint of that dataclass or type hint.

And of course mypy and other tooling can validate more things in a modern IDE due to the strictness in the typing if e.g. an int is accidentally used in a string operation, etc.

4. Correctly use the pyblish ecosystem

By avoiding using custom metadata like if instance.data["review"]: process_review() type of logic and instead tagging whether something say, has a reviewable or a certain type of media file, or certain type of representation through families means that ALSO the publishing system only ever considers it for processing for a plug-in if it has it. Instead of needing to know how a review product type differs in maya, to houdini, to blender, etc.

Similarly with all of the above steps it also means it's much clearer from e.g. a standalone studio addon to target e.g. family file.usd or alike that we KNOW there will at least be a USD file generated - and hence can basically add a stack of pre-integration file processors of that instead of targeting ALL instances and needing to search manually for representations, etc.

---

Testing notes:

1. Use together with PR here: Allow creating more product types as USD with USD contribution workflow and better defaults. ayon-houdini#144
2. In Houdini, start publishing USD model, groom and look products, each should work with their own validations but also with the asset contribution workflow. Each product should also have different defaults and target the right 'default layer'
3. Regular model publish in Houdini should also still work.

We may need to do a quick simple test across different DCCs that may define families data (at Creation, during publishing shouldn't make a difference) on the instance to see whether they still behave as intended. As far as I know that logic currently only exists inside Houdini and Maya.

[BigRoy]

Ready for merge @iLLiCiTiT ?

[MustafaJafar]

It works.