Shared project configs

[philip.scadding]

By default when you run the Toolkit advanced set up wizard for a project via Shotgun Desktop, you end up with a configuration created that is specific to that project. However, in certain setups you may wish to share your configuration with all your projects by default.

To do this you will need to setup a site-level distributed config.

1. Find the configuration you want to use. You can use the latest tk-config-default2 config (which is the default when using the setup wizard) or you can use a config from an existing project. But if you do use a config from an existing project, you must clear out the following files:

   

2. Now you need to decide where the config will live. It can either be uploaded to Shotgun, where it will be downloaded seamlessly in the background when the artist comes to work on the project, or you can store it on a network path. (There are other options as well, see the full list of descriptors) If your uploading it, just make sure you have zipped it up and move on to step 3, otherwise make sure it’s store in the desired location.

3. Now on in your Shotgun site create a global PipelineConfiiguration page,
   
   

4. On this new page create a new PipelineConfiguration entity with the following fields filled int:

   • Config name: Primary
   • Project: leave empty as we want it to apply to all projects
   • Plugin Ids: basic.*
   • Uploaded Config: If you are uploading your config, this is the field to upload your zipped config file. If you’re not uploading leave this blank.
   • Descriptor: Now this where you need to pick a descriptor to use. If your storing your config on your server location you would use a path descriptor something like this:

     sgtk:descriptor:path?linux_path=/path/to/config&mac_path=/path/to/config&windows_path=c:\path\to\config
     

   

5. If your config has a schema (if it’s based off tk-config-default2 it will do) then you will also need to set the tank_name field value on your project, before you can use it with your configuration.

Now all projects that don’t have a dedicated config will use this site config.
As a side effect, SG Desktop will also use this config, which means it won’t autoupdate unless you update your config.

[Johan]

Can a Tank Name have spaces in it? I’ve got a sneaking suspicion it can’t.

[philip.scadding]

I can confirm that you can’t have a project folder with a space in the name.

Even if you did put a space in the tank_name value on the project, and modified the process_folder_name.py core hook to allow spaces then you would get the following error:

TankError: The format string '{tank_name}' used in the configuration does 
not generate a valid folder name ('projects/mr upload')! 
Valid values are letters, numbers and the characters period(.), dash(-) 
and underscore(_).

[Johan]

Thanks Philip,

We’ll have to adjust then, I’m not looking forward in going over every single possible problem that could arise from this. We’ll conform to the standard thanks!

[nico.vandenbosch]

Glad I stumbled onto this thread since this seems to be the most effective way to manage multiple projects under a single config and avoid maintaining multiple branches. Any idea whether the removal of the install_location.yml, pipeline_configuration.yml, and interpreter*.cfg files in step 1) is strictly necessary? The only thing this seems to accomplish is removing the ability to launch the tank command in a default project context, which is arguably still a very a useful capability to have in a production environment. Are there known use cases where retaining these files could accidentally result in the default project context being set on another project?

[nico.vandenbosch]

My guess is there’s nothing keeping you from putting spaces in there, but since this (and other SG fields) are likely to show up in the filesystem as directory and/or file names it’s not the best idea to do so. Spaces in file paths are a nightmare for anyone who spends any amount of time interacting with files from the command-line since most tools and commands will use white-space as a delimiter for command arguments. Camel-casing or a carefully selected delimiter (’_’ is the most popular, but might confuse parsing if it’s also used in your toolkit templates) are good options.

[Rahul]

Hi,

I’v followed the above steps and created a site-config. Everything works as expected when I launch maya from Shotgun Desktop.

However when I bootstrap using script, then try to open file in maya using shotgrid menu > “file open”. I get this error “tank.errors.TankError: Cannot load core config file ‘/p/tech/pipeline/shotgun/config/core/install_location.yml’”

So I manually create this file. now it is complaining about “pipeline_configuration.yml” which I understand should not be created manually.

[Ricardo_Musch]

You should not create that file, something else is going wrong in the bootstrap process somewhere.
I’m running into similar issues atm with loading a distributed config on a farm.