Per-project delimiter as key in templates.yml?

Pipeline Integrations
1

Hey all,

Under the latest Shotgun configurations there was a move to use dots in place of underscores in naming for e.g. Assets or Shots. Here we want to maintain parity with what the Shotgun developers recommend, so newer Projects will follow the dot syntax. We have a mid-transition Project that has Publishes using the underscore syntax.

What I was hoping is that we could have a key in the templates file per Project called dlim (for delimiter), and that all the work & publish pathing and naming would include {dlim} instead of hardcoded dots or underscores. Then we would just change the default value of what dlim should be in the templates.yml based on the Project’s requirements.

In testing I made a new key in the keys section for a Project:

dlim:
        type: str
        default: "_"

…and then later in the paths section I do things like:

maya_asset_work:
        definition: '@asset_root/work/{current_user_name}/maya/{Asset}{dlim}[{name}{dlim}]{Step}.v{version}.ma'
        root_name: 'primary'

…I check to see that the template is giving back what I want in Maya e.g.:

current_engine.sgtk.templates.get(‘maya_asset_work’)
Result: <Sgtk TemplatePath maya_asset_work: assets/{sg_asset_type}/{Asset}/{Step}/work/{current_user_name}/maya/{Asset}{dlim}[{name}{dlim}]{Step}.v{version}.ma>

…and I have a test Maya file for an Asset that matches what should be the resolved path and filename.

When I try to use the in-Maya tk-multi-workfiles2 Shotgun UI, there are no complaints when I drill down to the Asset, but the UI doesn’t find the file to display and select.

If I change the {dlim} key back to a hardcoded underscore in those paths subkey values, it’ll find the Maya file and display it for selection in the UI.

What I’ve tried doesn’t work, so if anyone can point out what I’ve done wrong, or has a better way of tackling what I’m trying to accomplish here, I’m all ears (eyes?).

Cheers,

-DW

2 Likes
3

Hey Dean,

Thanks for the question. We can definitely see where you’re going with this but we’d need to test it out to confirm. Could you try adding a choices section with just _ as a choice?

That may help the template parser distinguish between the keys that are butted up together.

Another option is to try out is setting a filter that only allows that key.

Try those and let us know if it helps!

Best,
Tram

1 Like
4

Hi Tram,

So I tried:

dlim:
        type: str
        choices: ["_"]
        default: "_"

…and with a filter (regex):

dlim:
        type: str
        default: "_"
        filter_by: '^_'

…but neither of those worked either.

Cheers,

2 Likes
5

Hi @deanareeno

Yeah, it was a bit of shot in the dark.
I suspect what you’re trying to do won’t work, but the template parsing code is complex so we’ll have to dig in an test it to see what is going on there.

1 Like
6

Hi Philip,

It was worth a shot. Thanks to the two of you for the quick response. If in the future you discover a solution using the templates.yml, lemme know!

Cheers,

2 Likes