Using an in-house Maya Launcher

Hi there,

So this may sound like a stupid question for some more versed in the integrations, and there very well may be an answer in the docs (albeit i searched quite a bit and was unable to find an answer so far). But even if there is, I’d appreciate being pointed in the direction of that doc.

Anyway, I want to ask if there is a way to get the Shotgun Panel in Maya without starting Maya through Shotgun desktop.

Since we have quite an extensive pipeline already developed around using an in-house launcher (for better or worse), it would be a massive pain to try and get everything working using Shotgun Desktop.

Is there perhaps a doc somewhere outlining what environmental vars would need to be added and what scripts to be run, to get it up and running in an already running Maya for example?

Thank you!

Pete

Hi Pete,
We also use a custom launcher, which allows work to be completely when internet goes down… that’s the main reason we have these launchers…
I dont know if it helps you but it’s very easy to just point the software entity in question to a simple python.py instead of a strict C:/Program Files location for the .exe.
I’m not sure what your custom environment is doing, but you can absolutely just use your python/batch launcher in place of the strict program location.

If you are using the old shotgun config, you would just change the paths.yml to a path to your program_launcher.py
If you are using the new config2 then you could easily change the windows/linux/mac paths to your launcher.py paths.

This would be a hell of a lot easier than trying to bootstrap shotgun, and register the required frameworks, and then the shotgun-panel app itself…
-Ross

2 Likes

Hi Ross,

thanks for your input, it’s much appreciated!

From my understanding, your first outlined method would still require the use of the Shotgun desktop launcher, but with the maya.exe re-registered to point to our custom exe/bat, does it not?

If that is the case, Im afraid that would still be problematic in our case, because our launcher is a bit more robust (again, for better or worse, haha) in that there are a few checkboxes and settings, based off of which our custom Maya batch file actually gets created and run. Thats why I’m wondering if for example theres a way to get Shotgun Panel in an already running Maya, which hasn’t been started through the Shotgun Desktop specifically. I think that would give us the most amount of flexibility, as well as allow our users to not worry about a new Launcher system.

I will take a look at the other option with configs you mentioned, as that looks a little bit more intriguing.

Edit: Although, reading through the second option again, it seems it involved the Shotgun Desktop launcher again. Will research more when i have more than 5min of time between putting out fires, haha…

Again, my thanks

1 Like

Hey there,
Not sure if this is really possible, but it seems that once sgtk environment is loaded, SG Deskop is “just” launching maya with args through tk-multi-launchapp/prepare_apps.py and launch_apps.py

I imagine (and again, this is a blind shot in the dark) you can’t use engine without SG Desktop running, but you can open maya with engine as long as you have those args when launching maya.

2 Likes

Hey Ben,

Thanks for that, I will make sure to go through those and see if I can get it to load!

1 Like

So!

after the last post from benwall, it got me thinking that if it’s only setting an environment, i could try registering a new software using the tk-maya to our in-house launcher, posing as Maya. Sounded like a shot in the dark as Ben said, but it seems to have worked to get the engine loaded in Maya. That is, when Maya is then started from the in-house launcher, that has been started through Shotgun Desktop using the tk-maya engine. Phew.

Now… this is a band-aid solution at best, for several reasons.

  1. Our launcher supports more than one DCC, much like Shotgun, so picking only one engine that gets associated with it, is not even close to being ideal.
  2. More importantly, requires the user to use two launchers -> just… nope.

So, albeit this is a very hacky workaround, it can work, if your need is dire, I suppose.

It seems (from my rudimentary understanding of the system so far mind you, I could be completely off here) that Shotgun doesn’t provide an easy to use out-of-the-box solution for starting the engine in an already running Maya, almost forcing the user to use Shotgun Desktop, which gives me distinct Apple ecosystem vibes, which I’m most definitely not a fan of, hah, and I hope is not the case.
In the meantime, if anyone has any more information to share, I’d be happy to hear, since a nice solution is still somewhere out there.

1 Like

Hi Pete

We do!! Or at least I guess it depends on what you count as easy! :stuck_out_tongue:

You need to use our bootstrap API

We have a guide here on using it:

You can write a bootstrap script that runs within Maya, and you just need to tell it which project to Bootstrap essentially. Let me know how you get on with the guide and I’ll try and answer any specific questions you might have.

I also happen to have some code lying around for bootstrapping in Maya.

# This would run inside of Maya
import sys
# import a standalone copy of the sgtk API
sys.path.append("/Users/philips1/source_code/tk-core/python")

import sgtk

# optionally enable debugging, (not recommended for production)
sgtk.LogManager().global_debug = True

# Instantiate the authenticator object, passing in the defaults manager.
authenticator = sgtk.authentication.ShotgunAuthenticator()

# Optionally clear the current user if you've already logged in before.
# authenticator.clear_default_user()

# Get an authenticated user.
user = authenticator.get_user()

# Tells Toolkit which user to use for connecting to Shotgun. Note that this should
# always take place before creating a Sgtk instance.
sgtk.set_authenticated_user(user)

mgr = sgtk.bootstrap.ToolkitManager(sg_user=user)
mgr.plugin_id = "basic"

# bootstrap into the project context, rather than hard coding the project id, you could gather it from a previously set
# env var.
# We are not specifying a config, so it will likely resolve to the primary config
# on the project.
engine = mgr.bootstrap_engine("tk-maya", entity={"type": "Project", "id": 176})

tk = engine.sgtk

# make sure the path cache is synced
tk.synchronize_filesystem_structure()

Best
Phil

4 Likes

Hey Phil!

Well, good sir, that might be exactly what I’ve been looking for! Thank you for reaching out and correcting me!
I came across the bootstrap API before, but for some reason thought it not pertaining to my case, as the fact that it can be used for what I’m trying to do wasn’t clear to me for whatever reason.

I’m looking into it now, and just now seeing how much I have to catch up on all the settings in order to get it up and running and learn more about it. If I could then kindly take some more of your time, I would appreciate some help with the guide.

Im going through the Configuration Setup, and have a couple of questions.
(and again, this might be a couple of rookie questions, but I’d appreciate pointing to a topic with an answer instead of wasting your time, if that’s so.)

  1. We already have a project up and running with a ton of assets and custom entities. If i setup a configuration now, will it have any impact on the project, or does the config I would setup now pertain only to the way Shotgun gets integrated into a dcc?

  2. When setting up the Configuration, following the guide here, I’m getting an error at step #6. Clicking Continue with the “Default” selected, displays a “Downloading Config, hold on…” popup for a few seconds, and then an error message at the bottom of the window in red letters, saying “Shotgun attachment with ID 21572 is not a zip file”. (Attached is an image illustrating the problem). Am I doing something wrong?

  3. Assuming someone helps me figure out whats happening at #6, I’m wondering about the next step, #7 for several reasons, as I’m not sure what Shotgun considers project files. Seeing I’d like to have a centralized distribution of the Shotgun Toolkit, which I’m thinking to put in our version controlled repository, I assume the project files shouldn’t live in the same location (even though at the end of the guide it says the guide is for a Centralized Distribution?), as those seem to be local files? And the “configs” folder is probably where the standalone copy of sgtk API is gonna be put I assume? This part got me a bit confused, to be honest.

These are all for now, and looking at the guide now, I would think that should be it, in terms of getting this up and running.
The most important to me now, is if I do the config now (and am able to overcome the error the wizard throws), if it won’t break anything in the current project.

Thanks again Phil!

Hey Phil,

So I have tried to bite the bullet, and here is an update of the previous post:

  1. I hope it doesn’t, as from my - again - rudimentary understanding, it seems to only affect the Shotgun Engine

  2. I tried looking up the error message and came across a shotgun github, so downloaded that package as zip (master), and in the previous step instead of Default, chose to ‘browse’ and selected the downloaded Zip file from github. This seems to have allowed me to proceed past step #6 and onto #7, albeit i assume not an ideal workaround.

  3. I’ve reached a conclusion from reading through various manuals and seeing various screenshots, that project files may indeed be all working files, even though that seems weird to me. But either way, since we have an in-house asset manager, i assume it doesnt really matter where i set the project files, it’s just not gonna get used, so all i care about is the configs. Wrong?

One more question rose up during this though:

  1. Since I was able to proceed to step #7, i set up the projects path as per the manual, but when trying to click continue with all my paths set up, it threw an error that it needs tank core of at least 0.19.1 and mine is 0.18.something. (It would be nice if at this stage, from UX perspective, it redirected me to what to do about it, i thought, since i spent the better part of the afternoon finding out what to do and not able to do so, so writing here ^^) Which i can only assume results from me previously grabbing the master from github for step #5-ish, which had a unforeseen requirement of a minimal core version. Now, while i have been able to find a guide on how to update apps and the core, i was unable to follow it to fruition. The guide says run it from your project’s config, but thats the very thing i’m trying to setup, so there is none. i tried searching for the tank command in various places, but theres a couple of them scattered through the whole C drive (more than a couple in appdata/roaming, program files/shotgun, as well as various folders under our site’s name folder in appdata/roaming, which seemingly house similar things…), and even if i run a few of them with the “tank core” command, it displays the command prompt and asks if its ok to update and i press “y”, it doesnt seem to do anything.

Well… i think thats enough of an essay for now. Just thought i’d explain myself as much as possible to minimize the iteration time here.

Thanks again, Phil!

The configuration setup only affects the way in which Shotgun gets integrated into a DCC. So it should not impact your Shotgun Project in any adverse way. It will make a few changes in Shotgun, such as filling in the tank_name on the Project entity, and it will also create a PipelineConfiguration entity for your project, but neither of these things should have a negative impact on an already in progress project.

Usually, this only happens if your internet connection is a bit iffy. You could try clearing your cache in case there is something corrupted in there. However your workaround should be fine, just make sure you take the latest release rather than master, as master may contain untested versions.

I think perhaps you don’t really want the advanced setup at all. You don’t have to run the advanced setup wizard in order to bootstrap. The main advantage of the advanced setup is that it handles where files are stored, and as such has a few more apps, which take advantage of this.
Maybe not running the advanced setup is the way to go for you?

Yeah, you’re quite right in your assumptions. The config you downloaded from aster requires a higher version of core than SG Desktop is running, and this means it can’t set it up. The simplest thing to do here would be to go and download the latest release of the config from GitHub, assuming my suggestion of clearing the cache doesn’t fix the original issue, and that you want to continue setting up the advanced config.

I hope that helps?

Best
Phil