Hierarchical includes in environment config files

Pipeline Integrations
3

Hey Patrick –

I’m not sure I totally understand what you’re trying to achieve, but here’s some ifno that is hopefully helpful?

As I understand it, an include stands in as the value in a dictionary, at any level.

So you can have a include like this, where it’s getting a single setting on an app:

  location: "@apps.tk-multi-workfiles2.location"

(this is from config/env/includes/settings/tk-multi-workfiles2.yml)

Or you can have one that covers all of the settings, say for an engine, like this:

engines:
  tk-houdini: "@settings.tk-houdini.asset_step"

(from config/env/asset_step.yml)

But you can’t have an include and a “baked in” value for the same dictionary key – so this block from your second reply doesn’t make sense, as you’re defining both for settings.tk-nuke-writenode.shot:

# shot
settings.tk-nuke-writenode.shot: "@studio.settings.tk-nuke-writenode.shot"
  write_nodes:
  - file_type: exr
    name: Mono Exr, 16 bit
    promote_write_knobs: []
    proxy_publish_template:
    proxy_render_template:
    publish_template: nuke_shot_render_pub_mono_exr
    render_template: nuke_shot_render_mono_exr
    settings:
      datatype: 16 bit half
      metadata: all metadata
      colorspace: "sRGB"
    tank_type: Rendered Image
    tile_color: []

I think that answers your second question. As for the first, am I correct in my understanding of the problem? You have settings coming into a project from your shared studio config via include, but you want to be able to override those settings individually in a given project?

Our include system doesn’t really support overrides – it’s more designed with the purpose of not having to change things in multiple places, as opposed to “cascading” settings.

The one thing that might work (and I’m not suggesting this; it’s a hack) is take advantage of include file order. I’d have to test this to see if it’s actually reliable, but say you have a file set up like this:

includes:
 - file1.yml
 - file2.yml

setting: @value

There’s no explicit definition of which include file @value is coming from. So if it exists in both, which one wins? Again, we’d have to test this, but if the order is reliable – if it will get it in the first file it finds it, in the order they’re listed – then you could do something like this:

includes:
 - project-config.yml
 - studio-config.yml

And have the same include name (settings.tk-houdini.asset_step or whatever) in both. If it doesn’t exist in the first file, it will fall back to the second. Again, though, lots of unanswered questions with this approach.

Let me know if you still have questions; I went a little off-piste with that one :slight_smile:

2 Likes