Is it possible to substitute a different character for a space in a folder name than just a hyphen?

If a Shotgun entity folder has a space in the name, Tank currently substitutes a hyphen ('-') for the space when making the folder.  Is it possible modify this logic to use a different character?


Many studios have different conventions for this behavior so it would be great if this were customizable!


  • 0
    Ryan Mayeda

    Yes, this is possible as of the v0.12 release of Tank, which pulls this logic out of Tank itself and into a core hook.  This allows clients to customize the space-handling logic in Python through a mechanism that will persist through subsequent Tank platform updates, meaning Tank can continue to be updated over time but the core hook with the correct logic will remain in place and not need to be re-updated.

    To do this, find the script process_folder_name.py in the Tank core install folder ($root/tank/install/core/hooks/process_folder_name.py) and have a look at lines 68-69:

    # replace white space with dashes
    str_value = re.sub("\W", "-", str_value)

    To simply replace spaces with a different character, edit the script to use a different character.  For example, to get a period '.' set it as follows:

    # replace white space with a period
    str_value = re.sub("\W", ".", str_value)

    This will result in folders with periods instead of hyphens:


    More complex logic can also be used - configure what's required through Python!

  • 0
    Manne Öhrström

    What's also cool about this core hook is that you can validate the naming of things before they are created in the file system!

    If you for example had a naming convention which required all shot names to be on a particular form, you could add code to the hook described in Ryan's post above that would check the folder names and if a shot was incorrectly named, just raise an exception and Tank will not create that folder, but instead present the user with an error message.

  • 0
    Hadrien Huvelle


    It would be convenient that such renaming process is applied to the template path resolving. Isn't it?

    If i try this bunch of lines according your exemple:

    fields = {}
    fields['Project'] = 'ryan01'
    fields['sg_asset_type'] = 'Prop'
    fields['Asset'] = 'Martini Glass'
    fields['Step'] = 'Shading Lighting' #this is erity our former config , we wouldn't now use such as name with spaces... but somme projects are started like this...
    fields['name'] = 'scene'
    fields['version'] = 1

    path = publish_template.apply_fields(fields)

    With a template defined as follow: 'publish_template': <Sgtk TemplatePath maya_asset_publish: assets/{sg_asset_type}/{Asset}/{Step}/publish/maya/{name}/v{version}/{Asset}_{name}_v{version}.mb>

    path will be: 

    /prod/ryan01/assets/Prop/Martini Glass/Shading Lighting/publish/maya/scene/v001/Martini Glass_scene_v001.mb

    Wouldn't it be more logical to have something like this?



    Not sure if it's the right place this speak about this? Feel free to transform this in request if you find it more appropriated.

  • 0
    Ryan Mayeda

    Hi Hadrien!

    You're correct, the second path you list is the expected result.  However, by manually setting the values in your fields dictionary, you're bypassing the core hook that handles the character substitution and sending along your own explicit values, which in this case have spaces.  Instead of starting with an empty fields dictionary, try using the context as a base, with the as_template_fields() function:


    This will populate the fields dictionary with as much info as it can based on the context, and process the data through the core hook that handles the character substitution.  Then, you can add the additional missing fields yourself.  Here is an example based on the above - note how we grab the entities from the context and then add the 'name' and 'version' fields after:

    >>> context
    <Sgtk Context: Project: {'type': 'Project', 'name': 'ryan01', 'id': 64}
    Entity: {'type': 'Asset', 'name': 'Martini Glass', 'id': 638}
    Step: {'type': 'Step', 'name': 'Shading Lighting', 'id': 17}
    Task: {'type': 'Task', 'name': 'Test', 'id': 177}
    User: {'type': 'HumanUser', 'id': 39, 'name': 'Ryan Mayeda'}
    Shotgun URL: https://ryan-hosted.shotgunstudio.com/detail/Task/177
    Additional Entities: []>
    >>> publish_template = tk.templates['maya_asset_publish']
    >>> publish_template
    <Sgtk TemplatePath maya_asset_publish: assets/{sg_asset_type}/{Asset}/{Step}/publish/maya/{name}.v{version}.ma>
    >>> fields = context.as_template_fields(publish_template)
    >>> fields
    {'Step': 'Shade-Light', 'sg_asset_type': 'Prop', 'Asset': 'Martini-Glass'}
    >>> fields['name'] = 'scene'
    >>> fields['version'] = 1
    >>> path = publish_template.apply_fields(fields)
    >>> path

    Hope this helps!


  • 0
    Hadrien Huvelle

    Hi Ryan,

    Sorry for the delay. I understand very well what you mean. I was just hoping that I could "construct" the context by myself outside of SG.

    Has you can see in attachment, in order to help our team adopt the concept of tank (and import already done work from our former file structure) I did a little GUI lanched from our OS (not by SG then). The team have just to launch it, select the context and publish as often as they want (the window doesn't close after publish). For example a tracker working in PfTrack can save his work on the same file scene (done automatically on pftrack) and publish it by just switching to my publisher window. 

    This was in fact for us a workaround for pretty everything (while developing our proper apps). And honestly quite faster not to have to launch it from shotgun in order to change the context. 

    But thanks to your explanations, I think I see how to generate context by hand or by launching this app trough shotgun. 


    Kind regards

Please sign in to leave a comment.