Names for apps/frameworks specified via shotgun descriptors

We’re using app and framework descriptors of type “shotgun” to deploy tools remotely as described here:

This all works fine to a point. The configuration, apps, and frameworks all download themselves into a bundle cache on the client-side. However when the app is run, it crashes and burns when it explicitly attempts to import a framework by name using sgtk.platform.import_framework(‘tk-framework-studio’)

This seems to be due to the way toolkit assigns names to frameworks with shotgun descriptors:

print engine.apps.keys()
[‘tk-multi-vendordelivery’, ‘tk-multi-pythonconsole’]
print engine.apps[‘tk-multi-vendordelivery’].frameworks.keys()
[‘CustomNonProjectEntity02_5’, ‘CustomNonProjectEntity02_4’, ‘tk-framework-qtwidgets’, ‘tk-framework-studiowidgets’, ‘tk-framework-login’, ‘tk-framework-shotgunutils’]

Note the ‘CustomNonProjectEntity02_*’ frameworks are what we want to import, but we’re unable to identify it by name. Interestingly, our ‘tk-multi-vendordelivery’ app is also defined via a shotgun descriptor but gets to keep its name. Also noteworthy is that the ‘name’ field is disallowed on shotgun descriptors so how toolkit is arriving at these names is anyone’s guess. Is this a bug? Working as designed? Something we overlooked in the configuration?

1 Like

Hmm that is odd.

I had a go at replicating, but it seemed to work fine for me.

In my env/includes/frameworks.yml:

      type: shotgun
      entity_type: CustomNonProjectEntity02
      id: 6
      field: sg_payload
      version: 30398

In my Shotgun site I have a CustomNonProjectEntity02

In the custom app’s info.yml:

  - {"name": "tk-framework-randomnumber", "version": "v1.x.x" }

In the custom app’s code I have:

self._app = sgtk.platform.current_bundle()
print self._app.engine.apps['tk-multi-starterapp'].frameworks.keys()
rn = sgtk.platform.import_framework('tk-framework-randomnumber', 'tkrandom')
>> ['tk-framework-randomnumber']

So it imports and lists the framework under the app’s list of frameworks.

Is there anything different I might have done here to you?

That is odd Phil. Your repro steps are pretty consistent with what we’re doing. Nothing jumps out as different. We might need to take this into the debugger to see what noodly little detail we might’ve missed.

In the meantime, we’re successfully working around this by switching our framework descriptors to ‘path’ and embedding them directly in the pipeline config payload.


1 Like

Hi Phil,
Thanks for replying. That does seem to be the same issue.
I also fixed it by using a dev descriptor, but that isn’t really a lasting solution.
See if you can recreate it with an uploaded shotgun descriptor based engine definition (that uses {engine} field in the hook template).
I’ll have a dig around the code to see if I can find the source of the issue.

1 Like

Hah, that didn’t take long.

The shortname is derived from the entity type and version number.
This probably works from the assumtion that an uploaded config follows the convention of the app_store, but that won’t be the case for typical studio usage of the shotgun descriptor.

Either we’ll be forced to use the engine name as the toolkit bundle name for uploaded app/engines/frameworks (which isn’t viable given the website not providing any additional info on dropdowns in cases where you are trying to select a value for an entity field) or another approach to the shotgun descriptor system may be required; eg another field to override this behaviour, eg ‘system_name’ where one can enter the desired value, eg ‘tk-houdini’.

I’m not going to be able to offer a pull-request on a fix for this as the knock-on effects of changing the descriptor class behaviour are far and wide by the looks of it.


I’ve submitted a pull-request with a fix for this that appears to work.
The approach is to add a “system_name” field to the descriptor to allow users to override the default descriptor behaviour. I’m not sure how else this could be achieved as there’s no easy way for the code to know what the correct name of the toolkit bundle should be for the {engine} template field to resolve correctly.

1 Like