Better representation model based on OpenAssetIO

[antirotor]

Changelog Description

Using OpenAssetIO to replace represenation model in the future.

Additional info

This is adding OpenAssetIO framework to be used to resolve and publish data imbued with Traits and Specifications to handle
data previously impossible to get from simple representation model. It is not replacing immediately all legacy behaviour. It is adding it's own plugins so workflows can be slowly transitioned with backwards compatibility in mind.

Changes

This is adding support for running unit test directly in the addon context. For that, it provides repository level pyproject.toml with dependencies needed to run the tests. It is also including tests folder.

There is also root folder scripts with generate_traits.ps helper script to help to generate Traits in ayon_core.pipeline.traits.generated from YAML files.

This directory contains the traits and specifications for the OpenAssetIO
used across the pipeline.

They are defined in YAML files and OpenAssetIo-traitgen tool is used for generating the code from the yml files. This code is placed in the generated directory along with the __init__.py file that allows importing traits wherever needed.

You can use these traits in pipeline by importing them and using them like so:

from ayon_core.pipeline.traits.generated.openassetio_mediacreation import traits as mediacreation_traits
from openassetio.trait import TraitsData


data = TraitsData()
frame_ranged = mediacreation_traits.timeDomain.FrameRangedTrait(data)
frame_ranged.setStartFrame(1001)
frame_ranged.setEndFrame(1025)
frame_ranged.setFramesPerSecond(24.0)
frame_ranged.setStep(1)

data.hasTrait(mediacreation_traits.timeDomain.FrameRangedTrait.kId)  # True

# ImageTrait has no properties, it is just a "family" trait
mediacreation_traits.twoDimensional.ImageTrait(data)

pixel_based = mediacreation_traits.twoDimensional.PixelBasedTrait(data)
pixel_based.setDisplayWindowHeight(1080)
pixel_based.setDisplayWindowWidth(1920)
pixel_based.setPixelAspectRatio(1.0)

data.hasTrait(mediacreation_traits.timeDomain.FrameRangedTrait.kId)  # True
data.hasTrait(mediacreation_traits.twoDimensional.ImageTrait.kId)  # True
data.hasTrait(mediacreation_traits.twoDimensional.PixelBasedTrait.kId)  # True
data.hasTrait(mediacreation_traits.color.OCIOColorManagedTrait.kId)  # False

You can regenerate those traits from YML files by running the script
from /scrits/generate_traits.ps1.

It is also adding host.yml file to ayon_core that is needed by OpenAssetIO host interface configuration.

To use OpenAssetIO manager, you need to run code like this:

from ayon_core.pipeline import get_openassetio_manager

manager = get_openassetio_manager()
manager.resolve(...)

Important

Be aware, that getting manager is also initializing openassetio host and that can later on take some time. It would be better later on to do it once (per DCC host?)

Tip

More description coming

[iLLiCiTiT]

Suggested change

	kId = "Ayon:meta.FilesBundle"
	kId = "AYON:meta.FilesBundle"

[BigRoy]

Likely this requires the package bundle name to be uppercased here?

[BigRoy]

Can we provide better type hints than dict for this. First off, why can't we just have an actual Traits instance to pass in so we're correctly typing stuff. Or worst case scenario if there's so much need to be working with dict can we use TypedDict type hints to define what keys should exist, and what types those values are for those keys, etc.?

[iLLiCiTiT]

I guess the dict is here because each trait has different data requirement, and single item can have multiple traits, not sure how that should be type-hinted?

[antirotor]

traits_data is basically dict, but in OpenAssetIO world it is actually TraitsData type - here, I am trying to avoid pulling in OpenAssetIO dependency into common lib file. How this work:

# pseudo code
from openassetio.trait import TraitsData
from ayon_core.pipeline.traits import SomeTrait, OtherTrait


traits_data = TraitsData()

# now you can set traits data like so
SomeTrait(traits_data).setSomeData("foo")
OtherTrait(traits_data).setOther("bar")

# to check if trait is set on the data
if SomeTrait.isImbuedTo(traits_data):
    print("there is SomeTrait in traits_data")

# or it can be done like
some_trait = SomeTrait(traits_data)
if some_trait.isImbued():
    print("there is SomeTrait in traits_data")

# you can also check if the traits is in traits_data like
if traits_data.hasTrait(SomeTrait.kId):
	print("there is SomeTrait in traits_data")

Now, traits_data is something that will be serialized to json and stored in db (replacing representations in the future)

[antirotor]

Also I am thinking if it is good idea to reuse the representations key in an instance as I am doing here. Maybe in that case typing it explicitly to TraitsData would be better.

[ynbot]

Task linked: OP-1188 Define better representation model

[antirotor]

Closing this on slightly behalf of different approach:

• Define basic trait type using dataclasses #909
• New Traits based integrator #911
• Function to return type of representation #910