Distributed config app store location

Has there been a change to how desktop resolves where the bundle cache lives with distributed configs?

It used to be that it would grab my customized versions of apps out of
…/Roaming/Shotgun/bundle_cache/sg/{site}/v000000/bundle_cache/app_store/…

Now it seems to prefer loading out of
…/Roaming/Shotgun/bundle_cache/app_store/…

This is breaking a lot of apps where I’ve had to customize them for our pipeline.

I noticed it when upgrading the desktop client from 1.5.4 to 1.5.7 but I’m still seeing it after downgrading back to 1.5.4.

3 Likes

Hi Joe –

Great question. Lots to unpack here:

  • First off, your initial path looks right, but to break it down: …/Roaming/Shotgun/bundle_cache/sg/{site}/v000000/bundle_cache/app_store/…
    • sg = using a descriptor of type shotgun
    • {site} = your site, of course
    • v0000 = the attachment’s File entity id
    • bundle_cache because you have a bundle_cache/ folder in your uploaded config
  • The second path, …/Roaming/Shotgun/bundle_cache/app_store/…, does seem like a proper fallback path. So, Toolkit appears to be behaving correctly as far as using bundles in that path. It holds the bundles that come from the actual Toolkit App Store, rather than the ones that were included in your uploaded config.
  • I don’t believe that the update to your Desktop executable version was the reason for the change in behavior. However, it’s possible that in navigating Desktop, you landed somewhere (a project with no config, perhaps?) that caused the second path to be populated, when it was empty before, leading to the unexpected change in behavior you saw.
  • Having said all that, what seems to be the issue here is that you’re using the same version number in both cases, even though your custom bundles are not the same as the app_store versions. For example, if you have a custom version of tk-maya that’s based on v0.10.1 from the App Store, you’d want to call yours v0.10.1.1 or something like that.
  • I’ll mention that this isn’t purely a configuration issue. In this case, using app_store descriptors for bundles in a bundle_cache directory in your uploaded config is a bit of a hack; we don’t have a great workflow that we prescribe here. The app_store descriptor is a good bet because it doesn’t perform any lookup if the bundle is present in the cache. But it’s not totally accurate - these bundles aren’t coming from the app store. And it gets you in these situations. This has come up recently with the engineering team, but I’ll bring it up again.

Having said that, using unique version numbers for your bundles should address the issue.

Hope that helps! Let us know if you have any other questions.

1 Like

I think tried adding a ‘a’ to the end of the version string but that gave me an error.
I ended up changing the app names in my packaging script.

1 Like

Hmm, I’m not sure why that’s the case, but I think we’d need to dig into it more.

To be clear, I’m referring to the version field on your custom bundles’ location settings in your config’s env/includes/app_locations.yml and/or env/includes/engine_locations.yml files, and the corresponding folder within the bundle_cache folder in your uploaded config.

If you have a working solution, that’s great. If you want to dig into the version suggestion further, I’m happy to do that.

1 Like

Hello, just wanted to add a bit of extra information here: I just learned that there’s a {CONFIG_FOLDER} token that you can use in your descriptors to point to a path relative to your configuration location. So, instead of using an app_store descriptor (which, as I mentioned above, is a bit of a hack), you could use a path descriptor, and point its path value to

{CONFIG_FOLDER}/bundle_cache/....

It’s documented here.

2 Likes