New post
0

tank schema: non-static folders with 'hardcoded' names

Avatar
Sebastian Thiel
None
Follow

In order to adapt the tank schema to a folder layout which is grown naturally, the names of certain task and step related directories don't match with names of any shotgun fields. 

Also I have to defer the folder creation to when an actual task with a respective pipeline step is created, which seems to force me to use folders of type 'shotgun_step' , which are constrained to only be created if the step matches a given name. On disk, the created folder is named slightly differently though, and I would be catered best if I could just specify the name the folder should take, instead of being forced to the value of a shotgun field.

Is there a way to do that without using static folder types that I can't constrain to a $step, as there is no such folder in my schema.

Also I am not quite sure if doing so has a chance to work at all, as tank can't link tokens in the path to particular entities then, which might be required to figure out the context and entities of a path.

Thank you,

Date Votes

2 comments

  • 0
    Avatar
    Ryan Mayeda

    Hi Sebastian.

    Would you be able to share a more concrete example of what you're after?  It sounds like you've found this section of the folder schema docs:

    https://support.shotgunsoftware.com/entries/95441137

    But, this is for a static folder constrained by other Shotgun-based criteria.  If I'm understanding correctly, you actually want an entity folder that is not necessarily named based on an actual field on the entity?  I feel like I might not be following you 100% here so an example would help me answer!  It would be great to see what you have in Shotgun vs. what you want on disk, plus when you would want the relevant folders to be created.

    Thanks!

    Ryan.

  • 0
    Avatar
    Sebastian Thiel

    Hi Ryan,

    Sorry for the vagueness in my report - when I wrote it I knew an example would greatly help, yet the lazy dog in me won that day.

    This sentence of mine "... and I would be catered best if I could just specify the name the folder should take, instead of being forced to the value of a shotgun field." Actually contained the solution to my problem.

    What I had to do is to get a 'step' folder which matches what they already had on disk, which most of the time didn't fit any shotgun field available on a Step. Therefore, a custom field on the Step entity is the solution to having arbitrary names for step folders, as I can use the field to just specify the desired folder name on disk.

    It didn't help that the shotgun web frontend hides that fact that 'Pipeline Steps' are actual entities, and thus doesn't seem to allow listing or manipulating them outside of the designated pipeline step widget. Therefore I had to write a small script to add the field, and set field values according to my need. The problem here is that the client is unable to enter the required field next time a new pipeline step is created, which will be a maintenance problem and break things.

    To fix this, all you would have to do is to show Step entities when creating a view, for instance, which should open them up for standard manipulation.

    Something else I noticed about the disjunct folder schema and template system (among other things), is that folder schemas can be much more conditional than templates can be. This leads to the situation that you can create a folder structure that you will have trouble following with templates. The only way templates can be conditional is via environments, as you can alter your app-template configuration based on that. Adding more environments would just be an evil workaround though, which will greatly increase maintenance requirements - after all, environment specifications are quite redundant (a curse of sgtk, if you ask me).

    The final solution was to sit together with the client and explain the costs of trying to map their structure, to make him realize that bending it a little more towards what sgtk wants is the way to go, even if it means some obvious change. In an ideal world, that wouldn't have been necessary though.

    In short, to me this issue is solved.

    Best,

    Sebastian

Please sign in to leave a comment.