ynput / ayon-core

Apache License 2.0
25 stars 31 forks source link

Context Variables: Easy access to variables like episode, sequence, shot #533

Open BigRoy opened 3 months ago

BigRoy commented 3 months ago

Is there an existing issue for this?

Please describe the feature you have in mind and explain what the current shortcomings are?

It has come up a few times that easy access to your current shot context like Episode, Sequence, Shot would be nice. For example having environment variables set to matching values.

How would you imagine the implementation of the feature?

A potential idea could be to "get the folder name for each unique type of parent folder". So:

From my current folder /s01e01/seq01/sh010, go up any amount of folders - then ONLY for each parent with a unique type set an env var FOLDER_{TYPE}_NAME so that

- s01e01 (Episode)
  - seq01 (Sequence)
    - sh010 (Shot)

Would become e.g.

FOLDER_EPISODE_NAME = s01e01
FOLDER_SEQUENCE_NAME = seq01
FOLDER_SHOT_NAME = sh010

But e.g. this

- s01e01 (Shot)
  - seq01 (Shot)
    - sh010 (Shot)

(Technically valid in the backend) Would be:

FOLDER_SHOT_NAME = sh010

Are there any labels you wish to add?

Describe alternatives you've considered:

Not supporting this out of the box and consider this "studio specific" behavior. However it's been requested quite a few times by different studios so there may be sense to having some sort of 'generic' implementation that could work for those studios out of the box - even if not only specific to episodic work.

Additional context:

Came up on discord Came up on community forum: https://community.ynput.io/t/episode-name-in-naming-templates/1475

BigRoy commented 3 months ago

Note that this could potentially also get implemented from an addon as taskChanged callback in DCCs and somehow get it to also trigger on install and it should be possible as a studio specific implementation if needed. I believe @fabiaserra has a current working 'tweak' on OpenPype/AYON that does something similar so he might be able to offer explanation on his needs and the changes he implemented to make it work for them.

fabiaserra commented 3 months ago

the way we have it implemented is with this function https://github.com/fabiaserra/ayon-core/blob/release/alkemyx/client/ayon_core/pipeline/context_tools.py#L626 which we call here https://github.com/fabiaserra/ayon-core/blob/release/alkemyx/client/ayon_core/pipeline/context_tools.py#L588, here https://github.com/fabiaserra/ayon-core/blob/release/alkemyx/client/ayon_core/pipeline/template_data.py#L191, here https://github.com/fabiaserra/ayon-core/blob/release/alkemyx/server_addon/applications/client/ayon_applications/utils.py#L444 and some other custom workflows

BigRoy commented 1 month ago

Alternative approach: Use custom attributes in templates

Another approach for this could actually be Custom Attributes.

By having custom attributes with inheritance enabled it would mean that whenever sequence is specified all children are now part of that sequence (due to inheritance) unless stated otherwise. We'd then just need to have formatting access in the templates to custom attributes - which would open doors to much further customization.

fabiaserra commented 1 month ago

Alternative approach: Use custom attributes in templates

Another approach for this could actually be Custom Attributes.

By having custom attributes with inheritance enabled it would mean that whenever sequence is specified all children are now part of that sequence (due to inheritance) unless stated otherwise. We'd then just need to have formatting access in the templates to custom attributes - which would open doors to much further customization.

I don't quite get why we would do that if the information is already part of the folder hierarchy?

BigRoy commented 1 month ago

I don't quite get why we would do that if the information is already part of the folder hierarchy?

It achieves the same 'possibilities' whilst at the same time, allowing for even more customization unrelated to the actual hierarchy. Anyway, I also see merit in having the nearest parent folder name of a specific type to be accessible. But this 'alternative' would also solve the speed of the query itself (since we wouldn't need to query the parent - the data then also lives on the folder itself). Plus, since it allows for more may be a nicer option.

Anyway, just wanted to drop it here as alternative approach for the discussion. :)