Getting Project Name in

Hi there,

This thread is kind of a continuation of this one.

Basically, I’m trying to find the best way to set environment vars before artists launch their DCC.
I use a list of env var and values, and use a cmd command depending on the os
For instance on windows:
setx ENV_VAR_NAME "value"

:diamonds: > Takes too long to launch DCC if we set env var here (slow down from ~5s to several minutes!)

:diamonds: > pretty fast, but SG Desktop launch even if all the env var are nor created yet… Which means that users can launch Maya before plugins env var are setuped on their session. Not good!

  • Is there a way to force SGDesktop to wait for a my method to be over before opening the Project Apps pages?

:diamonds: > pretty fast too, but engine does not exists yet, so I can’t set project specific env var.

  • Is there a way to query the project name in this class? I would imagine so, as SG Desktop already know which config to initialise.

EDIT: It seems is also launched a second time once a dcc is launched - so impossible to use it for what I want.


1 Like

If your before_app_launch is taking several minutes to process I would wonder what is going wrong in the way you set env vars.

Could you post your before_app_launch code?

For example, if you are using setx inside a python script by using os.command or a subprocess that will definately slow down.

Why not just use os.environ[“ENVIRONMENETVAR”] ??


I have very erratic behavior with os.environ to set vars on windows. Env var don’t show up in System Properties when set with os.environ, for instance.

For instance:
:diamonds: In Maya Script Editor

print( os.environ.get('MAYA_SCRIPT_PATH') )


os.environ['MAYA_SCRIPT_PATH'] = 'test from maya'
print( os.environ.get('MAYA_SCRIPT_PATH') )

test from maya

:diamonds: Opening Shotgun Python Console
print( os.environ.get('MAYA_SCRIPT_PATH') )


os.environ['MAYA_SCRIPT_PATH'] = 'test from console'
print( os.environ.get('MAYA_SCRIPT_PATH') )

test from console

:diamonds: Back to maya script editor:
print( os.environ.get('MAYA_SCRIPT_PATH') )

test from maya

os.environ does not seem reliable when using several dcc.


Hi Ben

setx on windows sets the environment variable persistently across the operating system.

Usually though if you are setting env vars on the launch of an application, it is because you only want them to persist in the current environment/process only. This is good for env vars that will be set dynamically, such as storing the project id or something.
You should use setx if you want to perform a one time setting of the env var for the whole system, (good for values that don’t need to be changed.)

It’s not clear from your “Opening Shotgun Python Console” example where or when that is being run in relation to the env var being set.

If you set the env var in the Python Console in Sg Desktop before launching Maya then the environment variable will be set in the launched Maya instance, as it will inherit the current env vars.
But if you launched Maya first and then set the environment variable in the Sg Desktop python console, then the env var would not be present in Maya.

In summary I would say environment variables set via the os.environ have always behaved reliably for me.

1 Like

I want to set env var whenever a user load a config project, not whn he launches a DCC.
Depending on the project we are in, we will for exemple use different PYTHONPATH or OCIO env var, used by different DCC.


  1. Open Maya from already opened SG Desktop
  2. use script editor to set env var
  3. Open SG Py Console from the same SG Desktop
  4. use SG Py Console to get env var

I’ll try it out, it’s possible there was some confusion on my part

1 Like

OK great, thanks for clarifying.

Yeah the steps you detailed won’t work. Maya inherits the SG Desktop environment when it launches, think of it as taking a copy of the environment. The two are not continually linked so when you set something in Maya or SG Desktop it can’t then be accessed in the other, thats just not how env vars work (Nothing specific to Toolkit.)

That should be totally doable with the os.environ approach in the engine init. The engine_init is blocking so the env vars will be set by the time user gets to launch a DCC.
I think any weirdness you may have encountered probably came from the use of setx, I wouldn’t use that here.
Also env vars should be pretty much instant when set with os.environ, which is why I was confused that your before_app_launch hook was taking so long.

1 Like

I’ll keep you posted, thank ou you all for your help


I think also when using setx the current shotgun session wouldn’t inherit that environment variable.
Anything set on the system after Shotgun Desktop launches is not inherited. (That’s not a limitation of the system or shotgun, that’s just how it works).

Either use the engine init or the before_app_launch hook to set variables.
This will work fine for OCIO or those kinds of things.

We have a before_app_launch hook code that looks into shotgun to find a customEntity that stores Application information like Variables that need to be set for specific software and for specific projects.

We also have global variables set through active directory for our license servers and all those things .


So if I understand correctly, if I change an env var once SGDesktop has loaded the config then start Maya, Maya won’t benefit from the new env var? I have to reload the config?

1 Like

It seems to be working!


If you set the environment variable at any point whilst in the Shotgun Desktop project, before launching Maya, then Maya will inherit that env var (as a copy).
If you set the env var in Shotgun Desktop after launching Maya then it will be too late as Maya has already spawned and taken a copy of the environment.

1 Like

I switched to os.environ, and it seems to do the job. Env var will not appear in window’s env var parameter window, which is a bit strange, but it works!

Thanks a lot for the explaination.


If you are setting the env var with the os.environ it won’t be set in Windows environment variable configuration window, as it’s not setting it at a system level like setx, it’s only setting it for the current process, and any that spawn from it.
It is not persistent like setx, but as I mentioned that is usually what you want anyway for these sorts of things.