Templates duplicate

Pipeline Integrations
1

In the template.yml I define

asset_root: asset/{Asset}/{step}/{task_name}

Then I define

    asset_publish_area_maya:
        definition: '@asset_root/'

and

    asset_publish_area_photoshop:
        definition: '@asset_root/'

With Photoshop only the art pipeline step tasks will be made and with Maya only the model pipeline step tasks will be made
The result should then be:
Photoshop → P:\project\test\test_toolkit\asset\prp_testCube\art\sketch\prp_testCube_art_sketch.psd
Maya → P:\project\test\test_toolkit\asset\prp_testCube\model\draft\prp_testCube_model_draft.ma
… which are different resulting paths.
But I get the conflict error during init saying I have Templates Duplicates:

tank.errors.TankError: Could not read templates configuration: It looks like you have one or more duplicate entries in your templates.yml file. Each template path that you define in the templates.yml file needs to be unique, otherwise toolkit will not be able to resolve which template a particular path on disk corresponds to. The following duplicate templates were detected:
 asset_publish_area_photoshop, asset_publish_area_maya: asset/{Asset}/{step}/{task_lb_name}/

Unfortunately this naming convention is inherited and I have to stick with it for at least the next project I have to set up.
Is it just not possible to achieve this naming scheme, or is there a workaround any of you might see there?
Thanks in advance!

2

The easiest option is to have a single template asset_root, and the step would be filled in as appropriate. This is what I would do. Then you have to fix the users of these templates to refer to asset_root instead of the specific ones.

Another option is to hardcode the step art and model in the separate templates, which would make them distinct:
asset/{Asset}/model/{task_name}
asset/{Asset}/art/{task_name}
This is more hacky.

3

Thanks @mmoshev for the reply.
From your idea to hardcode the step value I would deduct that the checking of duplicates locations in the templates would be literal and not evaluating variables, which might be the case.
So what I did, and seems to be working, is defining publish and work areas as unique strings locations like so:

    asset_work_area_maya:
        definition: '@asset_root/snapshots/maya'
    # define the location of a publish area
    asset_publish_area_maya:
        definition: '@asset_root/maya'`

and then in my actual files locations:

    maya_asset_snapshot:
        definition: '@asset_root/snapshots/maya/{Asset}_{task_name}_{version_four}.{timestamp}.{maya_extension}'
    # The location of published maya files
    maya_asset_publish:
        definition: '@asset_root/{Asset}_{task_name}.{maya_extension}'

You will notice that in my publish location I’m not including the /maya sub dir as in the asset_publish_area_maya and the location '@asset_root/maya' is not even being created.
As far as now, this seems to work for me. I’ll post further if this workaround ends up being too messy or generating issues

4

Well that’s kind of expected… isn’t it?

What do you mean that the location is not created?

5

Well not really. I was expecting that a location with variables would be evaluated replacing the variable string with the variable value and that would not generate a conflict if I only use the variable as definition of a location (@asset_root/) wouldn’t it?

I mean that the folder @asset_root/maya is not created on the file system, and it does not clash with the fact that it is not defined in the folder’s schema (as far as my tests have gone)

6

nope, the template does not know ahead of time that the variable will take exclusive values. One could imagine such a mechanism, but then you would have to specify the possible values in the template definition. Otherwise you cannot guarantee there will be no clashes in naming.

This is odd. So the schema uses a variable folder, and does not match the hardcoded template? Not sure about this, I remember we had hardcoded paths similar to this, and they were getting created.

7

I see your point.

Maybe this is working just because I’m defining a location to the asset_publish_area_maya that I’m not really using afterwards in the actual maya_asset_publish? But I have to say that, at this point, it is not clear to me what is actually the asset_publish_area_maya used for :thinking:

Oh and from my experience (which is just starting in using the TK framework BTW) if I try to use a location in templates.yml that is not defined in the schema it will not create it and it will error if called by the create new file for example.

8

Then why do you need it? If it is not used anywhere you can get rid of it.
We also have quite a few dead templates, and need to find the time to clean them up.

9

Good point! I’ll test that.