To Pyblish or not to Pyblish?

[mustafa_jafar]

Hello,
Let me provide some insights about some current dev progress and suggested ideas.

@max.pareschi

Debugging tools
If we have dependencies, the graph add on is actually already suited to visualize that data. So you can know which connection goes where. Or maybe just a visualization node tree. Whatever fits really, but the hardest parts to debug right now are the ones enabled by pyblish design, which is multi in multi out.

We have a community post where we mentioned some debugging techniques for pyblish plugins Pyblish Plugins Debugging

Also, as a big fan of @BigRoy’s publish debug stepper.
I’d like to mention it was added as an experimental feature in Ayon Core in this Experimental tool: Pyblish debug stepper #753 | Core Addon

@max.pareschi

Ayon publish API
If you feel like reinventing the wheel it’s ok to do so, but there should be just one orthodox way of getting data. Like timecode or farm mode.

Some of the publish logic live in integrate.py which copies the files via and registers them in the DB.

There’s also a PR that implements an approach to “lower level publishing” which goes through pyblish. I think pyblish is hard to avoid since the whole pipeline is implemented as a set of pyblish plugins.

So, we may have a high-level API interface that goes like

# The system should end up allowing us to do AYON publishing in a simple way WITH type hinting across the board.
context = ayon.CreateContext()
instance = context.create(
    variant="Main",
    product_type="texture",
    files=["/path/to/texture.exr"],
    traits=[
        FrameRange(start=1001, end=1010, frame_list=[1001, 1005]),
        OCIO(path="ocio.config", colorspace="ACEScg"),
        BurninMetadata(camera_name="XYZ", username="roy"),
        TagsMetadata(),
    ]
)
context.publish()

I believe @BigRoy can share better insights.