App and Engine Reference

Apps and Engines Configuration Reference

This document contains an overview of all the different options that you can include when creating configurations for Apps, Engines and Frameworks in the Shotgun Pipeline Toolkit. It can be useful when doing advanced configuration of Apps, and it is important when you are doing development and need to add parameters to your App Configuration Manifest.

Introduction

This document contains specifications for the various file formats that Sgtk uses for its configuration and settings. Please note that this is a reference document which outlines all the various options and parameters available. For best practices on how to manage your configuration, please see the following document:

Shotgun Pipeline Toolkit Environments

Three major components exists in Toolkit:

  • An engine provides a translation layer or an adapter between a host application (such as Maya or Nuke) and Sgtk Apps. Apps typically use python and PySide, and it is the responsibility of the engine to present the host application in a standardized fashion and for example add pyside on top of the host application if this doesn't exist already.

  • An app provides a piece of business logic, it is essentially a tool that does something. Apps can be hand crafted to work in a specific host application, or they can be designed to run in more than one host application.

  • A framework is a library which can be used by engines, apps or other frameworks. A framework makes it possible to more easily manage code or behaviour which is shared between multiple apps.

An environment file contains the configuration settings for a collection of engines, apps and frameworks. Such a collection is called an Environment. Sgtk launches different environments for different files or different people. You can for example have an environment for Shot production and environment for Rigging. Each environment is a single yaml file.

Environment files are located at /<sgtk_root>/software/shotgun/<project_name>/config/env

The yaml file has the following basic format:

engines:
    tk-maya:
        location
        engine settings

        apps:
            tk-maya-publish:
                location
                app settings

            tk-maya-revolver:
                location
                app settings

    tk-nuke:
        location
        engine settings

        apps:
            tk-nuke-setframerange:
                location
                app settings

            tk-nuke-nukepub:
                location
                app settings

frameworks:
    tk-framework-tools:
        location
        framework settings

Each app and engine can be configured via settings. These settings correspond with the list of settings that the app/engine exposes in its manifest file called info.yml. As of v0.18.x of Sgtk Core, settings only need to be specified if they differ from the default values specified in the manifest file. In addition to the manifest file, the configurable settings can typically be found on the app/engine page within the Toolkit App Store.

In addition to the various settings that can be defined for each item, each app, engine and framework also needs to define where its code is located. This is done using a special location parameter.

Code Locations

Each app, engine or framework defined in the environment file has got a location parameter which defines which version of the app to run and where to download it from. Most of the time this is handled automatically by the tank updates and tank install commands. However, if you are doing hand editing of configurations, a variety of options are available for you to help deploy and structure Toolkit:

Toolkit currently supports app installation and management using the following location descriptors:

  • An app_store descriptor represents an item in the Toolkit App Store
  • A shotgun descriptor represents an item stored in Shotgun
  • A git descriptor represents a tag in a git repository
  • A git_branch descriptor represents a commit in a git branch
  • A path descriptor represents a location on disk
  • A dev descriptor represents a developer sandbox
  • A manual descriptor that is used for custom deployment and rollout

For documentation on how to use the different descriptors, please see the Toolkit reference documentation.

Disabling Apps and Engines

Sometimes it can be useful to temporarily disable an app or an engine. The recommended way of doing this is to to add a disabled: true parameter to the location dictionary that specifies where the app or engine should be loaded from. This syntax is supported by all the different location types. It may look like this for example:

location: {"type": "app_store", "name": "tk-nukepublish", "version": "v0.5.0", "disabled": true}

Alternatively, if you want an app to only run on certain platforms, you can specify this using the special deny_platforms setting:

location: {"type": "app_store", "name": "tk-nukepublish", "version": "v0.5.0", "deny_platforms": [windows, linux]}

Possible values for the deny_platforms parameter are windows, linux, and mac.

Settings and parameters

Each app, engine or framework explicitly defines a number of settings which you can override in the configuration file. These settings are strongly typed into strings, integers, lists, etc. For details, see the Toolkit reference documentation.

Follow

30 Comments

  • 0
    Avatar
    Milan Kolar

    One thing I cannot find in docs anywhere is how exactly does the toolkit figure out which environment to use in given situation. For example if I want a new environment specifically for modelling tasks on assets, how do I tell toolkit which .yml file to look at? 

  • 0
    Avatar
    Manne Öhrström

    Hello there Milan!

    Great question! This is covered in our howto docs which are more chatty and tries to explain what is going on (where as this is the reference documentation which is more focusing on how and what and not that much on why! ). Take a look at the following sections:

    If you don't find what you are looking for, let us know and we'll add it! 

     

  • 0
    Avatar
    Benoit Leveau

    I have made modifications to an app (tk-multi-workfiles) that are specific to our setup (so I don't want to submit them as a pull-request), how would I manage updates to this app?

    I'm thinking of the following:

    • clone the app repository in our git server

    • create a branch, where I put my modifications

    • replace the location values in the yml configurations so that it points to our git repo instead of the app store

    I'm curious about how can I then update it when you release a new version? I can pull the new version in the repo, then rebase our branch on the HEAD, and then the 'tank updates' command will find the new version? Is it how we're supposed to do?

    I guess then I need a way to check that there's an update to your git repo as the 'tank updates' won't connect anymore to the app store for this specific app, and it's up to me to have it up-to-date. A simple script that retrieves the git tags on your github would be quite easy to write then.

  • 1
    Avatar
    Manne Öhrström

    Hello Benoit!

    Excellent question! 

    We have been trying to expose a lot of studio functionality in hooks, with the idea that studios and productions can re-use the core part of the app (such as the UI) and the pipeline business logic can still be customizable. So the first thing to ask is whether the modifications you are doing would be suitable to run in a hook! If that is the case, we can always add (or you can submit a pull request with) the right entry point into the app and you can maintain your studio specific logic as a piece of hook code at your end.

    But sometimes changes aren't that simple (I suspect this is the case here!) and the changes that you need to make goes beyond the actual pipeliney tentacles that are expressed in the hooks - when you basically need to make behavioural or UI changes to an app!

    In this case I would suggest following the outline you suggest! Sounds spot on! Basically:

    • Clone and branch the app into your own git repo. Toolkit will use tags to handle version and upgrade, so it is probably best not to pull down any of the tags or branches from the shotgun git repo, basically only get the master branch.
    • In your own git repo, make your modifications and create a tag. Toolkit will interpret the tag as a version number, so we recommend that you name it on the form vX.Y.Z. 
    • In your environment setup, now take the configuration for the app that you want to replace with your custom version and modify its location configuration entry. Change the type to git and set your tag to be the version number and add a path parameter to point at your git repo (see examples above in the docs).
    • Once you have done this switch you may have to run the tank updates command. This will ensure that the git tag that you just specified is actually downloaded to your local tank installation.
    • Now run your setup - you should now be running your app instead of the original shotgun one.
    • Once you feel that you need to update your version of the app based on changes over in the Shotgun Repo:

    • Merge the changes into your master branch.

    • Create a new version tag (which has a higher number than the previous one!)

    • Now if you run the tank updates command, it should find and handle the update just like it would handle any update from the toolkit app store.

    The idea is that you can create (either from scratch or by cloning) your own apps, manage them in git repos (either locally or remote, like in github) and the maintenance and update commands that come with toolkit should be able to  handle this the same way it would handle an app update that has been published to the app store.

    Hope this helps! Let us know if you find any kinks in this workflow and we'll try to help iron them out!

     

  • 0
    Avatar
    Benoit Leveau

    Hi Manne,

    I finally got around to try this setup.

    I don't want to have different version numbers than yours for a few different reasons. So I followed this process for each app/engine:

    • clone the repository from your github
    • see which version we were using internally
    • checkout the same version (tag) of the repository
    • create a new internal branch
    • apply the changes we had internally to this branch
    • search for all the places in the yaml files where this app is used, and replace the type by git, and add the correct path

    All that on 35 repos. Luckily I could automate or create macros to do most of these.

    Correct me if I'm wrong. Did I just basically create an internal app store that will then be only used by "tank update" to copy new versions and install them in the shotgun/studio directory?

    So the location field has two (quite) different uses:

    • telling toolkit which code of the app to use, based on the "name" and "version" fields. At runtime, it will find the code in the studio install, in the apps/app_store/app_name/app_version based on these two fields.
    • telling "tank update" where the app store is (local git, local filesystem, distant github, etc.), in this case it uses the "path" and "version" fields. It will query the list of tags, then compare with the current version. If a newer is present, it will retrieve it and install it in the shotgun/studio area, then update the config file so it contains this new version.

    I'm now confused about how to keep the same version numbers as yours and still get my changes in these. I should retrieve your changes, rebase/merge my branch on yours, then recreate your tag after my merge? How is the version comparison actually done? I'm thinking of keeping your tags but adding a suffix or prefix, like "milk_v0.1.8" or "v0.1.8_milk". But in this case I would have to edit the "tank update" code to make sure we only allow such tags and ignore the others? This way I keep your version tags and branches without any problem.

    What do you think?

    Last question. How can I test changes to the apps? I have to localize the apps install to one project, then do my changes there, then copy the changes to the git repo, create a new tag, then use tank update to apply it centrally? Then I guess I need an extra internal patch number, so I would have a  v0.1.8.1, v0.1.8.2. I think I start to see why maybe having a different set of tags would make sense....

     

  • 0
    Avatar
    Benoit Leveau

    One final question, how do I specify that I want to use my local git repo for tk-core. This isn't listed anywhere in the yml files, as far as I can see.

    Cheers,

    Benoit

  • 0
    Avatar
    Manne Öhrström

    Hello Benoit!

    This is still a workflow we are very much trying to figure out so getting your feedback is great. We definitely will write up some guidelines and best practices for this later on, but right now I think we are at a point where we are trying to gather feedback from the community about what the best way forward is!

    Basically, we keep all our code in github. Whenever we release something, we don't use github, but instead, we first create a tag in github and then upload the code and the associated docs to our toolkit app store. This distinction makes it a little bit easier to orchestrate the process around distribution and make it a smooth process for less technical clients! 

    In the environment configs, toolkit by default tracks the location against the toolkit app store. This is done using the location dictionary in the configuration and we support a bunch of different ways to tell toolkit where to go look for the code and how to figure out when a new update is available! The app_store location tracks against the toolkit app store and the git location tracks against (numbered) tags in github.

    So when would you need to maintain a separate fork of an app repo? Well, I think ideally you don't want to do that! It is much easier to just use the toolkit app store. We try to provide ways to safely try out new releases from the toolkit app store before they get released to production using our pipeline configuration sandbox scheme. So, in my mind, I think there are two basic scenarios where running a fork in github makes sense (what do you think?):

    • A studio is adding a great feature that is missing or fixing a bug. In these cases, the ideal scenario is if they can contribute this back to the shotgun repo in the form of a pull request. Once we have pulled in the pull request and released it to the app store, the fork is no longer needed and the studio can go back and use the "standard" version.
    • There is a special feature that needs to be added that cannot be easily handled by something like a hook - and the feature may not be of general interest. In this case it probably makes sense to maintain a hook in parallel with the official shotgun master repo!

     

    In the case of forking a repo and then tracking it, I would suggest the following workflow as a starting point. I would love some feedback on this - I am sure there are many ways to do this!

    1. First, fork the app repo in github (in this example, we are forking multi publish!). You now have your own code! As part of the fork, you will receive all the tags and everything from the shotgun repo.

    2. Now, set up your local dev area. Add the shotgun repo as a special remote called upstream that you can pull from:

    > git clone git@github.com:STUDIONAME/tk-multi-publish.git

    > git remote add upstream git@github.com:shotgunsoftware/tk-multi-publish.git

    1. Now in your env configuration, switch your location to use your git repo instead of the app store: 

    location: {"type": "git", "path": "https://github.com/STUDIONAME/tk-multi-publish.git", "version": "v0.1.0"}

    1. Run the tank updates command to start toolkit tracking against the git location.

     

    Now -- What happens when the shotgun team releases an update? Well, on our end, we will tag up a version in github (v0.1.3 for example) and then push this to the app store. In your cloned repo, nothing will happen because you haven't pulled down those changes yet. So whenever we release a new version that you would like to release in your setup, how about the following steps?

    1. Get latest changes from the upstream repo and merge this with your master. This will pull down the new v0.1.3 tag as well as all other changes.

    > git fetch upstream

    > git merge master

    1. Now make sure that the changes are okay and that everything is fine. Since there is a brand new v0.1.3 tag that came down with that fetch, if you were to push the changes to github now and then run the tank updates command, the latest version tag would be v0.1.3 - and you would be prompted to update to this version of the code and not to your modified version. Therefore, once you are happy, create a new tag called v0.1.3.1 to symbolize that you are now merging the official v0.1.3 release with your own changes. This will be considered "more recent" than v0.1.3 by the tank updates command. And if you needed to make further changes using the v0.1.3 baseline, you could tag up v0.1.3.2, v0.1.3.3 etc. Finally, push changes and tags to github.

    2. Now if you run the tank updater, it will find the v0.1.3.1 version and ask if you want to upgrade to it. This version should contain the v0.1.3 code with your customized changes on top.

     

    What do you think about this workflow? It would allow for a controlled rollout of changes with the option to test and merge customizations!

  • 0
    Avatar
    Benoit Leveau

    Hi Manne,

    Thanks for the detailed workflow. This is roughly what I had in mind, except I didn't know about the upstream part and I'm not too familiar with the fetch operation, I'll have a look at these to make sure I understand it correctly. I created a list of all the projects, and the list of changes for each, and whether these changes are still needed / merged in the official branch, etc. There's only 3 projects which have modifications that haven't been "pull requested" and are still needed, so it makes the whole process less daunting.

    I realised the other day that in order to issue a pull request, I need to have my repository forked on github. When I retrieved your repositories, I cloned them locally, and did the changes on them. So to do the pull request, I had to fork it on my personal github, do the same change and issue the request. This was a one line change, so it was ok, but I'll have to see how to do that for the other projects. And also I have to check the implications of putting inhouse work on github.

    And to answer your question, I think it's a good workflow. I don't like the fact that you don't control which versions you're getting with the "tank updates" command, making it dangerous to run it on a test project then run it on a live project even a day after in case something was released in the meantime. At least with the forked repositories you're getting a bit of control.

    Benoit

  • 0
    Avatar
    Manne Öhrström

    Great stuff!

    Local git should be fine too - you can just send us a patch file, or even the whole app and we can take it from there! We just like github because it's so social ...and stuff! :)

    Regarding the "making it dangerous to run it on a test project then run it on a live project even a day after in case something was released in the meantime." part -- one thing we have talked about is the ability to basically "push" a pipeline configuration (like a dev or staging sandbox) to a production config. This way you could clone a tank sandbox, run the tank updates command there, and then do your testing. When you are happy you then basically just push those changes back to the Primary configuration. So no need to run tank updates on the primary configuration and running the risk that you get something new and untested. How does that sound?

     

     

  • 0
    Avatar
    Dave Lajoie

    +1 Manne!

  • 0
    Avatar
    Toke Jepsen

    Hey,

     

    Trying to get a good workflow for doing development and distributing to the primary pipeline. So I have some apps that I have forked off on github, and pulled down to the development environment. The environment config for a shot is then pointing to this path location. The problem is when I sync to the primary pipeline, where the path is now looking at the dev environment. This is not huge problem, as I can just edit the primary shot environment.

    I was thinking though that I could use github paths to keep the dev and primary seperate. But where does the local copy of the files go for the github referenced apps?

  • 0
    Avatar
    Manne Öhrström

    Hello Toke!

    My advise would be to use a "dev" location for your pipeline configuration sandbox, like this:

    location: {type: dev, path: /Users/manne/development/tk-multi-loader}

    For example, say that you wanted to make some custom changes to our loader app. You would then

    • First fork our official github version of the loader in git. Say that you are running your own github account, then your fork would end up in something like https://github.com/manneohrstrom/tk-multi-loader
    • Clone your forked version into your coding area

    • cd /Users/manne/development

    • git clone https://github.com/manneohrstrom/tk-multi-loader.git

    • Now inside of Shotgun, clone the primary pipeline configuration for the project you are working on in order to create your own pipeline configuration sandbox area.

    • Now in your cloned pipeline configuration, set up the dev location for the loader as shown above (pointing to your dev area).

    • You can now do development in toolkit on the project without affecting anyone else! 

    • If you want a TD or artist to try out your changes, you can "invite" them to your pipeline configuration by assigning them as a user in Shotgun. Your dev sandbox pipeline configuration will now appear as a menu item in Shotgun for that TD.

    Then, when you want to release your app to production, create a tag in git (for example v0.1.2). Note however, that if you are working on an app which you have forked from our repos, your version tags need to "play nicely" with the official version tags that we release. My suggestion would be that once you have merged any changes that we may have been making in the shotgun repo, then check what the latest "official" version tag is (for example v0.1.7). Now you want to basically tag up v0.1.7 PLUS your changes that you have made. Call this version v0.1.7.1. If you make further changes and want to tag another release, call this v0.1.7.2. Later, if shotgun releases v0.1.8 and you merge this with your cloned repo, you are now looking at v0.1.8 PLUS your changes. So consequently, when tagging this up, name it v0.1.8.1. (don't forget to push the tags from your local development area to github/git using git push --tags)

    Lastly, once you got the tagging going for your git repo, you can add the app into your production environment, this time using a git locator. So in the primary pipeline configuration for the project, use the following location:

    location: {type: git, path: https://github.com/manneohrstrom/tk-multi-loader.git, version: v0.8.1.1}

    The path here can be a url, a path on disk, basically any path that git would accept. The important thing to note is that this path is NOT a path to a local repo that you are doing development in, but it is a path to the repo that you are pushing your changes to (for example github, or a local git server you may be running).

    Now when you run the tank updates command, toolkit will basically clone that repo and extract the tag that you specified. Update checking will also work, so when version v0.8.1.2 is released, the updates command will detect this and ask if you want to update, just like you would with an app store app. The code will end up inside of toolkit's "app cache", looking something like this (cut down example for simplicity):

    Screen_Shot_2013-11-29_at_11.01.48.png

     Hope this makes things a bit clearer! We in the process of creating some more official documentation covering this workflow - soon there will be a development guide that will summarize all of this stuff in one place :)

     

  • 0
    Avatar
    Toke Jepsen

    Thats great, Manne! Thanks for the guide.

  • 0
    Avatar
    Toke Jepsen

    Hey Manne,

     

    So I have tiny bit of a problem with this workflow. It basically comes down to how to sync the dev and primary, and keeping the paths separate. We are using a simple file syncing program that will copy/delete files from dev to primary, to stay in sync with dev. The problem comes that I need to keep changing the paths in the dev environments, so when I sync the primary it is not looking at the dev areas paths.

    Is there a suggested way of keeping dev and primary in sync, but keeping the paths separate?

  • 0
    Avatar
    Manne Öhrström

    Hey guys!

    We have recently added a bunch of commands to try and streamline both configuration management and development! Here's a quick summary:

    • there is a push_configuration command which lets you push the configuration from one pipeline config to another.
    • there is a switch_app command that makes it easy to switch an app between app_store, git and dev mode
    • the install_app command has been updated so that you can install apps from git and not just from the app store
    • the setup_project command lets you set up a project based on a config which is cloned out of git

    We have tried to document some of these workflows here:

    Curious to hear what you guys think about these additions!

  • 0
    Avatar
    Benoit Leveau

    Hi Manne,

    I'm testing the new commands. I had to switch an app from app_store to git so it was the perfect time. I saw that the "tank updates" command now accept parameters to specify what to update in the form, with the possibility of using an ALL keyword:

    tank updates ALL ALL tk-multi-setframerange

    So I tried to do something similar when switching the app to git:

    tank switch_app ALL ALL tk-multi-setframerange /path/to/git

    But it failed as it expect a real environment and engine name, and doesn't seem to support the keyword ALL.

    There are 24 environment (we specialize them for steps, like shot_step_anim, shot_step_track, etc.) and a handful of engines, so it would be good to have support for the ALL keyword.

    I know most of the environment files all point to the same file through includes, so I could just update a few of all the possibilties, but it kind of defeats the benefit of having a tank command if I have to open all the files and check what is using what, and whether I thought about all the combinations.

    What do you think?

    Benoit

  • 0
    Avatar
    Benoit Leveau

    Another note:

    My cloned app folders are in paths that look like:

    /milk/code/shotgun/git/tk-multi-setframerange/

    When using the switch_app command, this path is detected as a "raw disk location" and not as "git" because it doesn't have the ".git" suffix.

    I know bare repositories should have ".git" suffixes but is it the intended behavior? I'll go ahead and rename my repositories to all have the .git suffix.

    Benoit

     

  • 0
    Avatar
    Manne Öhrström

    Hello Benoit!

    We don't currently support the use case where an app is cloned directly to a local repo and the changes are kept there. The system currently assumes that you are cloning into a bare repo, like if you would have cloned in github or are cloning to a local git server and then cloning from that server into your local dev area.

    How does your studio workflow look - when you share code between developers? Do you just clone off each others (non-bare) repos or do you have more of a central (bare) location and a git daemon running? We were thinking that most studios would have a central point where they kept their code and this is where you could 'drive' toolkit from.

    This is a very good point and something we should support! I'll add a ticket to our backlog. I am a bit worried about the workaround of renaming your local non-bare repos to .git - I suspect this may have adverse side effects with lots of other things :) 

  • 0
    Avatar
    Manne Öhrström

    Hello Again! Thanks for the feedback of adding ALL to the switch_app command. Great idea! I'll create a feature request for that one too!

  • 0
    Avatar
    Benoit Leveau

    Hi Manne,

    We indeed have a central point where we cloned the official repos of the apps and engines. It wasn't properly setup though as they weren't bare repos and the names didn't include the ".git" suffix (which is only a convention anyway, but a good one to follow).

    I renamed all my repos to .git and added symlinks with the old names, that I'll remove once I'm sure it doesn't break anything.

    This is a lot cleaner this way.

    For the ALL parameter, yes it's a bit tedious, I had to do some greps in the config giles to see which environment included the app, then run the command for each environment, then make sure I didn't forget any. The ALL switch would have helped.

    Benoit

  • 0
    Avatar
    Benoit Leveau

    Just to be sure, I meant we have a central point that then act as a git server from which we clone to our developer workspace. We do our changes in these developer workspace, then push the changes to the central point.

  • 0
    Avatar
    Benoit Leveau

    I have a question regarding the setup of our cloned repositories.

    The repos are in order:

    SG github --> a local bare repository --> the developer clone

    In order to retrieve the changes from SG, we need to run what you explained above:

    > git remote add upstream git@github.com:shotgunsoftware/tk-multi-publish.git

    > git fetch upstream

    Do you know if there's a way to run the upstream part in the bare repository itself? Because it already contains the github address from where it was cloned. I would have thought the upstream part was needed only if we forked your repositories on github but it seems it's still needed if we just cloned them (and not forked them).

    I hope my question is clear. It's purely git so I might find the answer myself but thought you'd maybe know.

    Cheers,

    Benoit

  • 0
    Avatar
    Manne Öhrström

    Hello!

    > Just to be sure, I meant we have a central point that then act as a git server from which we clone to our developer workspace. We do our changes in these developer workspace, then push the changes to the central point.

    Yepp, this is exactly the way it is meant to be used! As for setting up the remote against the bare repo itself, I am not totally sure! I'll try to find out! If you figure it out, let me know and I can update the docs.

  • 0
    Avatar
    Benoit Leveau

    After looking at this page I found the proper workflow

    http://stackoverflow.com/questions/8948803/what-does-git-remote-add-upstream-help-achieve

    Every time I want to retrieve your changes and merge with my changes, I need to do the following: (milkdev is our dev branch)

    $ git fetch upstream # retrieve your changes

    $ gitk --all # check that there are any changes on the shotgun side (if none, stop process)

    $ git checkout master # switch to the master branch

    $ git rebase upstream/master #  put the master branch in sync with the upstream one

    $ git checkout milkdev # checkout our development branch, make sure it's all committed and ready

    $ git rebase master # rebase our milkdev branch on the master one (reapply each commit from milkdev one by one, starting from the master branch)

    git push origin milkdev # push the rebase to the central server

    If we want to release as well, we can do:

    $ git tag -a v0.3.16.2 -m "Released for milk" 

    $ git push --tags # push the tasgs to the central server

    One of the important things, that I was stuck on, is the "git rebase upstream/master" that makes sure your local and central master branches are up to date with the upstream one, as you can't go in the central (bare) repository and do a git pull as it's not a working repository.

    Benoit

  • 0
    Avatar
    Benoit Leveau

    Just want to confirm that the ALL keyword is really needed. I want to test my changes above on an app and I have to type dozens of commands to switch all the apps. Also I discovered that you have - for the switch_app command - to use the name listed in the yml file and not the original app name.

    For instance, for the model step I have a "tk-multi-publish-model" entry in the apps section. I then have to type:

    tank switch_app asset_step_model tk-maya tk-multi-publish-model

    for it to work properly. Not sure it was intended. I'm renaming all my apps to just use the original names now.

    Benoit

  • 0
    Avatar
    Toke Jepsen

    was wondering whether you can have a type dict with arbitrary amount of entries?

  • 0
    Avatar
    Manne Öhrström

    > was wondering whether you can have a type dict with arbitrary amount of entries?

    Yepp, this is possible! Just omit the values parameter. For example in your info.yml :

    example_param:
    type: dict
    description: foo bar
    default_value: {"foo": "bar" }

    This is used for example in the loader: https://github.com/shotgunsoftware/tk-multi-loader/blob/master/info.yml#L42

  • 0
    Avatar
    kai

    Hi Manne Öhrström,

    Please help to to solve this error when i install app: 
    ERROR: Environment 'shot step' could not be loaded! error reported: 'str' object has no attribute to get

    Many tks!

    Edited by kai
  • 0
    Avatar
    Manne Öhrström

    Hi Kai!

    Try "shot_step" as one word and see if that helps. If not, I suggest shooting an email to our support - support@shotgunsoftware.com, include the command you are trying to run and the full error you are getting and they can help out! 

    Thanks!
    manne

  • 0
    Avatar
    kai
    Hi Manne Öhrström,
     
    With "shot_step" as one word, it's not working with "Unable to load shotstep.yml" error.
     
     Thanks and Best Regards!
Please sign in to leave a comment.