Multiple Configurations sharing the same install folder

Pipeline Integrations
1

[Extracted from a support conversation]

We have multiple configuration directories for our various projects and they always include the ‘install’ directory which we do not modify. Is there a way to specify a single install directory for multiple configuration as that would save us a lot of space.

1 Like
2

So it sounds like you are using a centralized setup, which by default have what we call a localized core. This is where each project has its bundle cache in the install folder.

It is possible to have all the centralized configs share the same bundle cache. You can set this up using the tank command via a terminal/shell/commandprompt. If you run the tank command with no args, then it will list out all available options. The ones that will be useful here are:

attach_to_core
--------------
When new projects are created, these are often created in a state where each
project maintains its own independent copy of the core API. This command
allows you to attach the configuration to an existing core API installation
rather than having it maintain its own embedded version of the Core API. Note:
If you don't have a shared core API yet, instead use the share_core command.

...

localize
--------
Installs the Core API into your current Configuration. This is typically done
when you want to test a Core API upgrade in an isolated way. If you want to
safely test an API upgrade, first clone your production configuration, then
run the localize command from your clone's tank command.

...

share_core
----------
When new projects are created, these are often created in a state where each
project maintains its own independent copy of the core API. This command
allows you to take the core for such a project and move it out into a separate
location on disk. This makes it possible to create a shared core, where
several projects share a single copy of the Core API. Note: if you already
have a shared Core API that you would like this configuration to use, instead
use the attach_to_core command.
...

So the first thing to do is run the share_core command on one project to create a non project specific core, and then you can run the attach_to_core command on the rest of your projects to link them to the same shared core.

Note however that these commands won’t actually remove the app_store folder from inside the project-specific install folder, you will need to empty this your self once you’ve attached it to the shared core. Only empty the app_store folder and any core.backup folders.

Another option is to look into distributed configs, they can still be centrally stored using a path descriptor. By default the bundle cache is then kept on the user’s local drive cache, but it can be redirected using the environment variable SHOTGUN_BUNDLE_CACHE_PATH .
However, even when you do that, it will still create a copy of the actual core per-project config on the user’s local cache, but all apps, engines, and frameworks could be stored centrally. The nice thing about distributed configs is that you can set up a default site-wide config, which means you no longer need to have a project-specific config if you don’t want to.

4 Likes
3

Hi @philip.scadding

with regards to

The nice thing about distributed configs is that you can set up a default site-wide config

Could you elaborate on that a bit and maybe give an example how to set this up ?

Regards
Stu

2 Likes
4

Hi @sogrday,

Check out these docs;

I believe @philip.scadding had linked them above, you can follow the walkthrough in our Developer site - https://developer.shotgunsoftware.com/5d83a936/ and chose the distributed config method in the wizard.

To utilize this on a site wide level, follow the second doc I linked where it shows how to utilise the descriptors to set an uploaded config as your primary set the part on self contained configurations.

-David

3 Likes
5

Thanks! I’ll see if any of this helps.

1 Like
6

Hi,

I’ve been experimenting with a distributed configuration pulling from a git repo. This works fine if I’m using the desktop app but how am I able to instantiate sgtk from within a python script? I’ve relied up to this point on grabbing the configuration path from the pipeline configs of the project.

Let’s say I’m running a script on a render node that may not have shotgun desktop installed. How would I run the toolkit from there?

Thanks!

1 Like
7

I’ve made some progress. For users with the distributed installation, I will use their local tk-core for connections to sgtk. For anything that has to run server-side I will use a forked repo of the tk-core from github.

I’ve encountered this error when trying to bootstrap an engine, however

raise ConsoleLoginNotSupportedError(hostname, "Single Sign-On") tank.authentication.errors.ConsoleLoginNotSupportedError: Authentication using username/password is not supported on the console https://shotgun.xxx.com for sites using Preformatted text Single Sign-On.

Any idea how I can authenticate in the presence of SSO?

Thanks!

1 Like
8

The above issue I was able to seemingly resolve.
However I’m encountering another issue with authenticating:

tank.util.errors.UnresolvableCoreConfigurationError: Cannot resolve the core configuration from the location of the Sgtk Code! This can happen if you try to move or symlink the Sgtk API. The Sgtk API is currently picked up from \\pathto\config\core which is an invalid location.

The core location is neither from an install folder within the user’s local install or the shared location of the tk-core. Is there a way to get around this?

1 Like