Duplicate strings in the templates.yml not allowed, why?

Pipeline Integrations
1

I’m encountering an error while loading Shotgun desktop.
It complains that I have two separate string definitions in the templates.yml that both have the same content.
I understand why you can’t have duplicate path definitions because otherwise sgtk cannot find a context from path.

But strings I don’t think need that limitation? Or do they?

I’m using the strings section to define a comma separated list of shotgun fields that a client would like to receive in their submission sheet. Some clients may have the same requirements which means I have the exact same data in the definition.

2 Likes
4

Hi @Ricardo_Musch,

Sorry for missing this one for a while. Is there any error you are seeing? We probably need to see your template.yml file to get to know more. Could you please file us a ticket at support@shotgunsoftware.com with the error as well as your template? We will help you out in that thread.

Cheers,
Ben

1 Like
6

It might make more sense to store the value in a new project entity text field and pull it from there in your tool?

1 Like
7

Yeah, I agree with @Patrick, I think the setting are probably best stored somewhere else, in Shotgun or in the environment yml files on the app settings. If multiple apps need the same settings you could use the include syntax to include them into multiple app setting blocks.

For the record though, the strings section is treated the same as the paths section, in that the values must be unique.

1 Like
8

Hmm, thanks guys.
Unfortunately I don’t see any way of adding the types of information I need in there in anywhere else than the templates file.
However I found out that if I even add just one extra space in the second string it treats it as a new string instead of a duplicate so I think I’ll just go with that for now.

Unfortunately I cannot store this info on a field in Shotgun unless I would make a custom entity and create records like that. Maybe in the future!

1 Like
9

  • On your Sg site, open the “projects” menu, and click on “view all projects”.

  • Then, click on the “fields” button and select “Manage Project Fields…”
    image

  • Then click “Add new field”
    image

  • Give the field a name, make sure the type is set to “text” (This is the default).

Once you have that, the field can be shown on your main projects, view and producers/td’s can edit the contents (your list of delivery fields).

From your delivery script, you can then use the following call…

sg.find_one('Project', [['id', 'is', 123]], ['sg_client_delivery_fields'])

… to get your project, and with it, the field you just created (beware the fieldname will be prefixed “sg_”).

Can you share the code where you’re pulling the list from templates.yml? Maybe I’m misunderstanding how you’re aiming to use the data?

1 Like
10

Ay, I know all that :wink:

If it would be something I’d do on shotgun I’d have to create a fields that tracks multiple custom entity’s which I’d need to set up and configure pages for.
And I’d need to save path template’s in there or keep track of the the paths in the templates.yml.

My aim is simply to keep all the configuration for this in one place and since it uses paths keys for generating client export paths I wanted to keep all related setting information in templates.yml by using keys.

And before anyone mentions “You can set settings on apps”.
That wouldnt work, basically each path key I define in the templates.yml which starts with a specific code (i.e. “ce_” for “client export”) will be read, decoded and appended to option lists.

Example:

ce_client1_shot_exr: some/path/to/file.ext
ce_client2_shot_mov: some/path/to/other/file.ext
ce_client2_shot_exr: some/path/to/another/file.ext

This would create export options in a gui for client1 and client2

  • client 1 has export options for only exr
  • client 2 has export options for exr and mov

(Above is just an example)

Unfortunately I can’t share the code for this.

I think What I’ll do is see how badly the “extra space” fix can screw up.

The alternative now would be to read a custom text file instead of a yaml file and write my own interpreter for it, which is not a problem at all.
Just wanted to keep things in the same places :slight_smile:

1 Like
11

Right, I see.
Well, you can fight the system and end up with a mahoosive templates.yml as you add new clients. Or you can bite the bullet and go down the route of custom entities/fields. I did this before and it was pretty awesome. You could configure not just paths, but encode parameters directly from the website. If you have someone tech savvy in production then they can even handle configuring deliverables themselves.
It’s a fair bit of work though, so your other suggestion of a seperate file is probably your easiest bet.
The “extra space” approach sounds a bit too hacky for my tastes, but whatever works ! :slight_smile:

1 Like
12

I’m still not sure why the app settings wouldn’t work for you though, especially if you are considering a custom format? App settings can be any data type YAML supports, so you could have a list, or dictionary of lists, or just a dictionary:

some_app_settings:
    client_export_options: 
        client_1:
            exr: some/path/to/file.exr
            mov: some/path/to/other/file.mov
        client_2:
            exr: some/path/to/another/file.exr

The app could then load all the settings in and display them in the UI.

Forgive me if I’ve missed something though.

1 Like
13

Hmm, that is true actually.
Okay I was wrong there…

Let me think on this one.
For the moment I’ll go with the hacky space solution but will plan some proper website/entity setup for the next release.

I was just a bit confused as to what the reason was for the strings section not allowing duplicates.
I can see why for the paths, but not sure about the srings.

2 Likes