Moving over from the old `tk-config-default` to `tk-config-default2

Pipeline Integrations
1

If your config is based on our old config (tk-config-default2) and you’re thinking of updating to the new config, (tk-config-default2) then you’ll need to understand what’s changed in the new config and how to apply your customizations over to the new config.

First off we have this which talks about the changes that were brought in with the basic integrations (tk-config-basic). Some of what is covered here also applies to tk-config-default2.

Differences

The key changes between the configs are as such.

  • A new environment YAML structure. The deafult2 config now has a much more modular structure, where includes (@) are used much more to split the configuration out over multiple files. This makes it much easier to see the settings for a particular app or engine in one config. Before the env/project.yml file would contain the majority engines and apps that were required for the Project context, now these are all separated out and chained together using the @ syntax.
    For example the project.yml links out to the Maya settings:
    https://github.com/shotgunsoftware/tk-config-default2/blob/v1.2.11/env/project.yml#L41
    which are stored here:
    https://github.com/shotgunsoftware/tk-config-default2/blob/v1.2.11/env/includes/settings/tk-maya.yml#L61
    That, in turn, links out to separate files for apps, frameworks and locations.
    The “Editing a config” and “Adding an app” guides may provide some help here.

  • No shotgun_{entity_type}.yml files. Previously there were files like shotgun_project.yml which were used to define the apps available for the browser integration. Now, however the logic for deciding the environment to use for the tk-shotgun engine runs through the pick_environment.yml which brings it in line with everything else. So your normal environment YAML files now contain tk-shotgun engine sections as well. If however, you don’t have a tk-shotgun engine defined in your environment YAML, it will still fall back to looking for a shotgun_{entity_type}.yml file.

  • Software entities. The majority of the software launchers are now controlled via software entities.

  • The schema and templates haven’t really changed much.

  • The tk-multi-launchapp hooks, have changed to allow working with Software entities. As there is now a generic settings block used for all software defined by Software entities, the hooks now include the engine name in the passed args. This is because it is a generic settings block, when you define your custom hook, it will be called for all software, so you need to use the engine_name parameter to check if it is an engine you want to act on, before doing any software specific logic.

  • New publish2 app. The hooks and settings here are very different from the first app. You can find the publish2 app reference documentation here and a this tutorial covers writing plugins/hooks for them.

Strategies for updating.

There isn’t a golden path here as such.
The first thing you should do is figure out what you have customized on your current config. Performing a dif between our old default config and your existing one would quickly show you what you have changed.

Once you’re aware of the changes you can then start working through them and applying them to the new config. There isn’t a simple apply changes approach here, you will need to translate your app settings over to the new environment YAML structure. Templates and schema can probably be directly copied.
For somethings, it might be better to test out the new config’s settings before deciding to carry over old settings.

Please feel free to post below if you discover something worth mentioning that I missed or have any questions around it!

3 Likes
2

So I’m moving our configs from our old style into the new style and I’m hitting a wall on being able to launch apps from a Task.

I’ve worked out that it’s down to the logic in pick_environment.yml.

We used to have this:

    if context.entity and context.step:
        # we have a step and an entity
        if context.entity["type"] == "Shot":
            return "shot_step"
        if context.entity["type"] == "Asset":
            asset_id = context.entity['id']
            if sgtk_from_entity("Asset", asset_id).shotgun.find(
                    "Asset",
                    [['id', 'is', asset_id]],
                    ['sg_asset_type']
            )[0]['sg_asset_type'] == "Still":
                return "still_step"
            return "asset_step"

However Shotgun isn’t happy with that and I get errors like this:

Shotgun engine failed to start using the legacy start_shotgun_engine routine. No more attempts will be made to initialize the engine. The start_shotgun_engine exception was the following: TankMissingEnvironmentFile(u’Missing environment file: V:\pipeline\shotgun\sgtk_configs\newstyleconfig2\config\env\shotgun_task.yml’,)

So it seems to be falling back trying to find shotgun_task.yml again, which obviously isn’t there in the new config. I think this is because of it using sgtk_from_entity as a test, which is bugging it to fall back, as even on an Asset step and not a Still step, it errors and is trying to find shotgun_task.yml, even though for the Asset step logic it should just return the Asset step as the base code does…

My question is how can I alter my logic so that it will not try and fall back? Thanks very much.

2 Likes
3

Hey Jon!

You shouldn’t need to use the sgtk_from_entity you can just use self.sgtk.shotgun to get the API instance.

Beyond that, you need to make sure that the environment it picks, contains the tk-shotgun engine in it, and that the entity type allows PublishedFile being linked in Shotgun, other wise it will fall back to the legacy method.

2 Likes
4

Hey Phil! Thank you, that sorted it right out!

2 Likes