Hi,
I noticed that the Mash plugin has a userSetup.py and it ends up executing before my userSetup.py. I know that I can deal with execution order in several ways, but I wonder what people do when there is already a userSetup.py that belongs to a plugin or some other toolset. Do you consolidate the different userSetup.py into a single userSetup.py or is there a better solution?
Thanks in advance!
Richard
Generally I’d aim to get my own stuff to be as order-independent as possible. If you’re not explicitly referencing, say, Mash in your own tools it doesn’t really matter much who loads first: in fact it’s good vegetable-eating to make sure you’re not accidentally depending on order-of-execution side effects which might change in a future version.
TLDR: If you’re good about doing checking dependencies when they matter (for example, you ensure that menus you want to patch have been initialized) you should be relatively safe from order dependencies. It’s always better to assume the worst, since you can never be sure some user has not got a script or plugin you don’t know about.
If you want to go for a more draconian approach the last option is to intercept Maya at launch by going straight into a command you pass in on the command line : maya.exe -c myStartupCommandHere or maya.exe -script path\to\myFile.mel Going from the command line is usually a good choice – it will let you get in very early and execute before standard userSetup.py but you can also pass arguments in, for example, telling Maya which project you want it to run. This is usually preferable to relying on system wide stuff like environment vars. Both the -c and -script flags expect Mel, not Python, but all you need is enough Mel to get your paths set up and to import your python; you can even write python to generate the Mel you would need so you don’t feel dirty about it (example here) . The easy out is maya.exe -c "python(\"execfile('path/to/the/file.py')\").
Finally you can also defer just the loading of some of your own stuff by creating a single point of entry – your one “startup function” – and calling it inside a maya.utils.executeDeferred() That will simply wait until Maya has processed its first GUI Idle event, which means most things will be initialized… apart from those crappy old school mel scripts that don’t fire until somebody does something like click a menu. Those, you may need to isolate an manually source if you depend on them. For example if you want to add something to the file menu at startup, you will need to call the MEL buildFileMenu() before trying to mess with the menu, or it may not exist yet.
One thing to keep in mind is that in an ideal world your tool environment won’t blow up if you run headless in MayaPy – but executeDeferred does not exist in MayaPy where there is no GUI. Strict separation of the UI from the functionality with a little bit of “am I in GUI mode” should keep things safe there.
PS if you search the site for “maya startup” you’ll get a whole bestiary of info on this topic 
@Theodox Thank you so much for the detailed reply. Lots of good info there. The one key thing I was missing from mel days is that maya runs every userSetup.py script it finds in paths. I was under the impression that it will only run the one it finds first. Thanks again! 