Python Maya startup script

Hi
I want to run a python script whenever i start maya.How this can be done?

%MAYA_APP_DIR%/scripts/userSetup.py

%MAYA_APP_DIR% is an environment variable that defines where the root of your chosen Maya data directory is located. Usually defaults to something like C:\User\yourusername\Documents\maya.

You can write scripts in userSetup.py or call/import others.

There are considerations to make whether this is personal (in which case Michael’s answer is great) or for distribution, in which case you may want to consider other options.

You can also have a userSetup.py in each of your script path and they will all get executed one after another at startup.

When doing this for userSetup.mel, I’ve found that only the first instance found in the path gets executes (like all other MEL scripts). So users could in this case override your server/P4/SVN located userStartup.mel with a local one… not that good. But as said it’s not as big a problem with userSetup.py. Now it all comes down to executing order, and user script folder is among the first ones so any server/P4/SVN located scripts will normally run last (depending on how you add your custom script path to Maya).

if you launch maya from a customized short cut, or from the command line, you can pass maya a script to execute when it launches. I believe this file has to be a .MEL script, but it can execute python commands within it.

we use this feature to separate the local userSetup files from the stuff we want to globally distribute to the whole team.

[QUOTE=vifx;13529]Hi
I want to run a python script whenever i start maya.How this can be done?[/QUOTE]

I wrote down some stuff about this on my blog a while back. It’s more detailed in case you want a better idea of what is possible. Actually I’ve been wanting to do another installment of this after I have since had lots more experience doing this for personal and studio-wide distribution. Much, much more can be done with python to make something like this a very powerful approach to configure maya. However, your needs are probably pretty simple so I wouldn’t overload you with that. Feedback welcome! I want to cater to people who are exploring, and I don’t want python to seem intimidating for the beginner to novice group.

http://www.jonasavrin.com/2011/02/18/maya-env-configuration-of-variables-using-usersetup-mel-and-usersetup-py/

good stuff, we also ignore userSetup.mel, userSetup.py and maya.env.
those are still there for individual users to modify if they want certain tools, but we have moved the start-up procedure for maya into source control. We have a batch script that configures the user’s environment for all our tools, but one of the things it does is create a new shortcut on the desktop to maya that handles setting up the environment variables and system paths.
One of the benefits of doing it this way is I still have the original, native maya shortcut avilable as well. If i ever need to isolate bugs or crashes from our tools, i can easily launch a clean, factory version of maya.

[QUOTE=rgkovach123;13644] We have a batch script that configures the user’s environment for all our tools, but one of the things it does is create a new shortcut on the desktop to maya that handles setting up the environment variables and system paths.
One of the benefits of doing it this way is I still have the original, native maya shortcut avilable as well. If i ever need to isolate bugs or crashes from our tools, i can easily launch a clean, factory version of maya.[/QUOTE]

This is awesome. Your environment variables are still set to non-factory settings though, when you run the clean Maya though, correct? Or are you resetting them beforehand?

The environment variables are only set within the single instance of maya, since we run it through a command shell. Therefore the system itself is never permantly modified and doesn’t need to be reset.
Native Maya and our customized Maya live side by side with no conflicts.

There’s never a reason to modify persistent global state for your pipeline. There’s never a reason to break that rule. Kovach is exhibit A.

I am very interested in figuring out the tool deployment technique rgkovach123 mentioned in his posts. rgkovach123 could you or anyone else point me to a tutorial or some docs that might help me to deploy environment var and such as described above, without affecting a default Maya startup.

Thanks for any pointers to where to look and read.

any ideas as to why userSetup.py wouldn’t be called? It’s placed in:

C:\Users\username\Documents\maya\2013.5-x64\scripts

it always gets called, it just gets called really early while Maya is loading so it can’t really effect the startup scene, since the scene isn’t fully constructed yet.

we basically have three steps for distributing maya tools. None of which affect the default installation of maya or any of it’s environment variables.

First we have a simple python program that collects information about the environment - where perforce, where maya is, etc. This program also creates a new desktop shortcut for maya with a unique name so it isn’t confused with the regular desktop shortcut. This program isn’t run very often, basically each time a new version of the tools are pushed to the team.

Second we have a special MEL script simply called mayaStartupConfig.MEL. This MEL file just calls python scripts which are deferred until maya is idle.

Third we have a second python program that is called. This is what the new Maya shortcut runs instead of the maya.exe. This python program sets the Maya Env Vars and then calls maya.exe with -c flag pointed to mayaStartupConfig.MEL file. This basically allows you to give maya another script to run when it loads in addition to the userSetup files.

So now i have two desktop shortcuts for Maya, one that is custom and one that is native. Individuals users can modify maya.env, userSetup.mel, userSetup.py however they like, and they will work under both conditions.

1 Like

thanks passerby, I was using prints to test and i guess it gets executed earlier than the script editor takes over stdout.

I just use a userSetup.py that checks our distribution server for the latest tools (they live there as zip). If needed it downloads the zip and includes it in sys.path. If I want to opt out for any reason I just remove the custom userSetup.

I just use a userSetup.py that checks our distribution server for the latest tools (they live there as zip). If needed it downloads the zip and includes it in sys.path. If I want to opt out for any reason I just remove the custom userSetup.

In passing I’d point out that using p4 directly is not ideal unless you oblige everybody to force-sync your distribution files every time. You’ll always have .pyc files lying around (which usually are not checked in) so it’s possible have ‘phantom’ modules left over from earlier runs which may get picked up and executed, leading to a lot of head scratching as you see errors that literally dont exist in your python files but do exist in the pyc. You can either check in PYCs (bad if you have to support multiple OSs or bit depths – and I’m not sure python respects the flags) or delete them before your sync

How would this translate for a OSX setup?

[QUOTE=rgkovach123;20601]we basically have three steps for distributing maya tools. None of which affect the default installation of maya or any of it’s environment variables.

First we have a simple python program that collects information about the environment - where perforce, where maya is, etc. This program also creates a new desktop shortcut for maya with a unique name so it isn’t confused with the regular desktop shortcut. This program isn’t run very often, basically each time a new version of the tools are pushed to the team.

Second we have a special MEL script simply called mayaStartupConfig.MEL. This MEL file just calls python scripts which are deferred until maya is idle.

Third we have a second python program that is called. This is what the new Maya shortcut runs instead of the maya.exe. This python program sets the Maya Env Vars and then calls maya.exe with -c flag pointed to mayaStartupConfig.MEL file. This basically allows you to give maya another script to run when it loads in addition to the userSetup files.

So now i have two desktop shortcuts for Maya, one that is custom and one that is native. Individuals users can modify maya.env, userSetup.mel, userSetup.py however they like, and they will work under both conditions.[/QUOTE]

This might be relevant to the discussion here:

1 Like

@TheMaxx

My experience with userSetup.py is recent, so I could be incorrect, but the default behavior I’m seeing is:

The first userSetup.mel found in a script path is run when the gui loads, and all others found are ignored.

However: All userSetup.py’s found are run(order agnostic). BUT, they run before the GUI so not all commands are respected, or ready to go when these happen.

One useful method if using only userSetup.py is the executeDefered():

So a userSetup.py may look like this:

import maya

maya.utils.executeDefered(‘yourMethodName()’)

def yourMethodName():
#do python stuff here once GUI’s loaded.