Dynamic variables in templates.yml possible?

Pipeline Integrations
1

Hi !

The current tk-config-default templates.yml
is basically configured per dcc and step, like this:

…
shot_work_area_maya:
definition: ‘@shot_root/work/maya’
…

I was wondering if I could write this more dynamic, like

…
shot_work_area:
definition: ‘@shot_root/work/@dcc_name’
…

I am not quite sure how I could dynamically resolve those
variables like “dcc_name” (or other dynamic vars) in a correct way,
I tried using env vars in the .yml file (putting $VAR as the dcc_name) but that did not work at all.
(Or did I just write it in a wrong way?)

I found kind of an answer here:

But this thread is already 5 years old and I was wondering if there is a more recent solution to this.

Any help would be appreciated,

cheers

Sebastian

1 Like
3

Hi Sebastian –

The exchange that you linked to predates my time at Autodesk by about a year, and.I hadn’t seen it before. I have a feeling that that “large scale engineering refactor” that Manne mentioned either didn’t happen as such, or didn’t include this change, and I don’t see an internal ticket that would have been tracking this request, nor do I see it mentioned in the File System Configuration Reference.

So… I don’t think there’s been much movement here, unfortunately. I’ve put in a ticket to track the request. I have a feeling it would require a bit of design on the engineering side, though – I don’t think it’s a quick fix. Nevertheless, I’ve linked your post to the internal ticket, so I’ll be notified when it’s resolved, and will notify you in turn.

I will mention one other thing – I wonder if it would make sense to track this info in Shotgun, perhaps on the Task or Pipeline Step, then pull the info into your templates from there?

1 Like
4

Hi,
thanks for the answer.

By “tracking the info in shotgun” you mean create a link, for example writing the dcc name into a field on the task?

I dont really see how that would work dynamically - it would require me to do the linking every time somebody, for example, uses the tk-multifiles2 saver and klicks on a task to resolve the fields?
Sounds like an overload to me here.

One idea might be to use the “additional entities” list in the context, which could be dynamically filled/added/extended (is that even possible?) with my required and missing entities (in this case “dcc”, done in the context change hook f.e.), and therefore have all required keys available when trying to resolve the templates.

There is an explicit warning in the docs to avoid using the “additional entities”,
I am not really sure about that anymore… but would this work somehow?

Anyways, thanks for tracking this issue,
I am curious about a solution here!

cheers
Sebastian

1 Like
5

I just wanted to throw some more weight behind this idea. There is a world in which the following replaces 95% of my templates. It’s a world I’d love to be living in!

versioned_file: {name}_{step}_{version}.{ext}

# Work templates
asset_work: {root}/{project}/assets/{asset}/work/{app}
shot_work: {root}/{project}/shots/{shot}/work/{app}
asset_work_file: @asset_work/@versioned_file
shot_work_file: @shot_work/@versioned_file

# Publish templates
asset_publish: {root}/{project}/assets/{asset}/publish/{app}
shot_publish: {root}/{project}/shots/{shot}/publish/{app}
asset_publish_file: @asset_publish/@versioned_file
shot_publish_file: @shot_publish/@versioned_file
4 Likes
6

Hi,

I just wanted to share a possible solution/hack for this:

First, it is not a very elegant way, and it does not seem to work for every sg app.

The main idea behind this is to use the “Additional Entities” on the context,
what gets used when resolving any templates:

  1. In the context_change hook (post_context_change), I extracted the current engine.name,
    queried a shotgun Software entity with this engine name and put this entity in the
    “Additional Entities” list into the current given context.

  2. When starting any software, now a software entity with the correct current engine.name
    is automatically available in the “Additional Entities”

  3. In the templates.yml I created a key like this:

dcc:
    type: str
    shotgun_entity_type: Software
    shotgun_field_name: engine
    subset: 'tk-(.*)'

and a test template like this:

shot_work_dcc:
    definition: 'shots/work/{dcc}'
  1. Running this python code in maya, i get my desired path:
import sgtk

tk = engine.sgtk
context = engine.context

template = tk.templates['shot_work_dcc']
fields = context.as_template_fields(template)
path = template.apply_fields(fields)

So, this could be a way to extract data from any entity in SG for the templates, even if it is not linked to anything.
Unfortunately, it did not work for the tk-multi-workfiles2 app,
the folders got created correctly, but then failed to validate the context here:

self._environment.work_template, validate=True

because “Software” is missing:

…could not be populated by context ‘animation, Shot sh001’ because the context does not contain a shotgun entity of type ‘Software’!

Which kind of makes sense, since there is no context change (and therefore a “Software” entity available via the context change hook) before it gets queried… :thinking:

I will investigate further into this, maybe some custom minor code changes
the the core api / context.py could help here…

hopefully there will be an “official” solution to this in the near future since it would really
help with templating maintenance… :slight_smile:

cheers
Sebastian

2 Likes
9

Hi all –

@sebastian.brandhuber, thanks for sharing that solution. After running it by the team, it does seem a bit “brittle” – like you said, it doesn’t work in Workfiles, and while it works in the direction of getting from a context to a path, context_from_path() wouldn’t work in certain circumstances. I’ll also mention: there is a `context_additional_entities core hook. It’s very much deprecated, and has been for a very long time (“It probably doesn’t do what you think it does and it will likely be removed in a future release.”). I’m not recommending you use it, just mentioning that it’s there.

If there’s a feature request in here that you think would facilitate this workflow, I encourage you to submit it. Thanks!

1 Like
10

@sebastian.brandhuber Did you get any further with this Sebastian? I have a similar issue with workfiles not working due to the context not being able to resolve the Step folders parent folder as a SG entity in the context. This is where my Step folder parent is a customEntity, not a Shot.
I guess the question is given a path of form /<my_custom_entity>/ how do we get SG to include <my_custom_entity> in it’s resolved context on context change?