Delivery: support per-representation template overrides - #1960
Delivery: support per-representation template overrides#1960jakubjezek001 wants to merge 5 commits into
Conversation
Allow delivery functions to accept an explicit anatomy template object
instead of looking it up by name in the project anatomy. This enables
dynamic template overrides based on representation rules.
Also includes:
- New delivery tool settings models for template override rules
- Support for `{publishedFilename}` without extension in templates
- Integration of override lookups in the delivery UI logic
Implement template overrides for representation delivery and fix an issue where frame numbers were incorrectly included in directory paths when using the publishedFilename token. Also corrects the settings path for delivery overrides.
ynbot
added
size/S
type: enhancement
jakubjezek001
changed the title
There was a problem hiding this comment.
Pull request overview
Adds configurable per-representation delivery template overrides via project settings, allowing studios to override the delivery directory/file templates based on representation name (instead of being locked to a single delivery template).
Changes:
- Introduces new Delivery settings models under global tool settings to define override presets and representation rules.
- Updates the Delivery UI to load override presets from project settings and build an explicit anatomy
TemplateItemper representation when a rule matches. - Extends delivery pipeline helpers to accept an
explicit_template_objand adjusts{publishedFilename}handling for templates.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
| server/settings/tools.py | Adds Delivery settings models and defaults for per-representation template override presets. |
| client/ayon_core/tools/delivery/delivery.py | Loads delivery override presets from project settings and builds explicit template objects per representation; updates {publishedFilename} handling. |
| client/ayon_core/pipeline/delivery.py | Adds support for explicit template items in check_destination_path / deliver_single_file and includes frame-related path adjustments. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| "delivery": { | ||
| "enabled": False, | ||
| "overrides": [], | ||
| }, |
| # Remove frame number if is find in folder path | ||
| # usually due publishedFilename token used in directory | ||
| frame = anatomy_data.get("frame") | ||
| if frame is not None: | ||
| frame_pattern = f".{frame}" | ||
| if frame_pattern in delivery_folder: | ||
| delivery_folder = delivery_folder.replace(frame_pattern, "") | ||
| delivery_path = os.path.join( | ||
| delivery_folder, os.path.basename(delivery_path)) |
| filename, _ = os.path.splitext(publish_basename) | ||
| template_data["publishedFilename"] = filename | ||
| args[0] = src_path |
| # make sure if file or directory is in template it is | ||
| # wrapped into double braces so it is not formatted | ||
| # e.g. "{directory}" should be "{{directory}}" so it is not | ||
| # replaced by the format method |
| for src_path, frame in sources_and_frames.items(): | ||
| # Support {publishedFilename} token | ||
| template_data["publishedFilename"] = os.path.basename( | ||
| publish_basename = os.path.basename( |
There was a problem hiding this comment.
Why this? This is supposed to be filename, not basename. Filename has extension. It doesn't make sense to change extension of a file during delivery.
|
This PR adds multiple things at the same time. I would split it. First of all if someone needs to use the filename as a directory -> without frame and extensions, then don't change I really don't like that we do add different delivery templates to the settings. Rather add an enum of delivery templates from project anatomy, with that you don't need the |
There was a problem hiding this comment.
I somewhat agree with Kuba here. This is just overcomplicating things and I really wonder whether we're not stretching it too far. And with the amount of complication this adds, I feel like it doesn't solve enough. The pure single representation name switching I think doesn't suffice.
Would people maybe want to differentiate certain representations within a single delivery template, sure. Would it be up to representation name only - I don't think so. Also, what if you have two representation names you now want to apply this delivery template to, etc. (or what if camera_exr, exr and raw_exr or whatever special representation names you may have from ingests. The design doesn't scale well. It'd almost need to be profile filtering based, etc. (but we all know how complex that can get to set up in settings)
It's really getting to the point where it just starts making more sense for the delivery tool to be able to specify custom delivery rules/scripts, like a "use this script to define the template" where you can essentially put in your own custom Python script to evaluate it to something custom, etc. because we're seeing the granularity that studios want their deliveries to behave like for their needs. Especially with AI/LLMs being able to write some custom logic would be trivial? We could have a custom delivery format where you get access to the "context" and e.g. just return the template you want to apply. Complexity for the admin? yes, but allows you to get very granular and move the responsibility to the one maintaining the delivery system not having to dive deeper and deeper into growingly scattered and complex settings?
In short, I wonder - are we solving this the right way?
|
Perhaps the "batch delivery" 'script' approach we discussed could apply here too @jakubjezek001 ? |
Changelog Description
Adds configurable overrides for delivery templates on a per-representation basis. Studios can now define override presets in project settings that swap the directory/file template for specific representation names, instead of being locked to a single delivery template. Also adds support for using
{publishedFilename}without its extension in templates.Additional info
DeliveryToolModel,DeliveryTemplateOverrideModel,DeliveryRepresentationRuleModel) expose override presets under Delivery tool settings, matched by representation name.check_destination_pathanddeliver_single_fileaccept an optionalexplicit_template_objto bypass the named anatomy template lookup.{directory}/{file}tokens from the original template when only one side is overridden.{publishedFilename}(without extension) is used in a directory token.Testing notes:
Dependency
Close #1961
Related support tickets
YN-0942