I’ve created “Maya Foundation”, a small tool to make Maya load scripts from any folder. My intention when I started was to make it a tiny bit easier for a small company without a full-time TA to get into scripting. Some places copy scripts around manually and stuff and it just gets ugly real fast. So if you need to get a bunch of Mayas up and running now-now-now then maybe this is helpful.
Anyway, check out the website and if it sounds interesting just grab the tool and let me know if it’s helpful.
The installation process is as easy and visually pleasing as I could make it, so as not to piss off the artists. You just have to decide on a folder everyone can access, then have everyone run the installer and select the folder. That’s all there is to it.
I’ll check it out, although I’ve just implemented a new setup process where I work.
Seen and implemented a few different script/plug-in setup variations at different developers over the years, so it will be interesting to take a look at.
Thanks, yeah if you try it let me know if it makes sense.
Out of curiosity what sort of solution did you come up with?
For reference, all Foundation does is altering the user’s userSetup.py file to execute a “sharedUserSetup.py” file in the folder of choice. Nothing too complicated. Does that share traits with your system?
Well, it’s just a way to make Maya load scripts from a specified folder. Project-dependent logic belongs in the scripts you decide to run.
Choosing an empty folder during installation creates a “sharedUserSetup.py” file that is executed on Maya startup. And now everyone else can install and choose that same folder, which makes their Maya’s also run this sharedUserSetup file during startup. It’ll be up to you to extend the template sharedUserSetup file to actually launch the tools you require.
Basically Foundation aims to make it easy for a new hire/formatted computer to get up and running quickly by simplifying the steps needed: Just select the proper folder and that’s it. Ideally an artist would need no more information than the website and the folder you want him to select.
The code is completely open (and pretty simple) so if you spot only a small nugget of interest you’re free to rip it out and use it as you your own. code.google.com/p/mayafoundation/ has the sourcecode.
I like the explicit nature of userSetup.py to configure Maya because it is inherently a per-Maya setting. I’ve not used a sitecustomize file myself, but afaik it is a solution for configuring your python environment rather than anything Maya specific no? Can you elaborate on the use of sitecustomize in relation to Maya startup? It sounds very interesting.
The task I wanted to solve was “How to make Maya load scripts on startup”, and for that I think relying on userSetup.py functionality (which Foundation extends with sharedUserSetup.py) is a simple and semantically correct choice.
For the third time in as many companies I’m come into a system where everything is relying on the users editing the maya.env file for setting up the scripts and plug-in paths, I would call that method the stone age way…
At the second company we implemented a launcher platform (in C#) where the user simply selected project and the application and launch, and that setup dynamic environment variables on each launch of the application. All scripts and plug-ins where in P4 and auto-synced on each launch. This required nothing of the user as it even launched the correct Maya version used in the project that was selected.
Now at the third company, people are against a launch application so the current system I’ve setup is based on Maya’s modules setup system that plug-ins like Havok utilizes. The only thing that exists on the users computer (besides what is in P4) is a .txt file with the module path for both common and project specific tools under <user>/maya/2011/modules. So syncing P4 and copying this file to the right location is all the users need to do the first time (which we will automate with and installer together with some other stuff soonish). Syncing tools in P4 is done automatically when the user login as we think that is often enough. Then in the module path in P4 I use usersetup.py for most stuff, but also sitecustomize.py for setup of the subfolders in the script hierarchy.
The downside I’ve seen so far with this system is that usersetup.py in a module is executed too early, way before the Maya interface is created, which it doesn’t when in the users Maya folder. So for now I’ve added a usersetup.mel in P4 as well for interface modifications, as that runs after the interface is created even in modules. This created a dependency that we have to check that the users don’t have a local usersetup.mel file as it overrides the one used in modules, which is easy to do and they can still have their own usersetup.py so it’s not a big deal as we just have to convert the files when they are found.
At the first company we ended up with something similar besides it was all MEL and no Python back then, so back then the user could not have a usersetup.mel file either but there as no usersetup.py file for them to fall back on so it was limiting the users personal setups a bit more then it does today, which was not good but not a problem now with Python.
Haha yes WolfSong, relying on everyone manually setting up their environment sounds brutal. Just Say No™ I like the idea of a proper launcher, we’re rolling out something similar these days (ours is more of a background service) and it shows a lot of promise. Excited to try it out.
Using Maya’s module system sounds like a clean and simple solution though. What Maya Foundation does is create a file in the user’s local scripts folder, it could easily instead create (or copy) a file into the modules folder if you’d like it to. Just thinking out loud.
Can I assume by using the modules system you are also granted plugin- and icon-paths, in addition to a new scripts path? In some ways it sounds like an even cleaner solution than what I do with Foundation, I’ll have keep this in mind for v2 The conflict you describe between userSetup.mel/py files sound really annoying though.
Can you explain how you use sitecustomize for subfolders? Do you add the folders to sys.path? If so what are the advantages over sticking an init.py file in the folders so they becomes importable?
BTW, the early execution of userSetup.py (and in the case of Maya Foundation sharedUserSetup.py) is something to get used to for sure. You need to defer execution of functions that rely on UI, e.g.:
import maya.utils
def executedDeferred():
"""These commands are run after Maya is done initializing, so here we do
have full access to Maya functionality"""
print "Hello dear world"
maya.utils.executeDeferred( executedDeferred )
And thanks UncCheezy. uMen sounds interesting with all the features it provides. Maya Foundation is literally just about initializing shared scripts (but no functionality beyond that as of yet) so I look forward to hearing if and how it fits your needs.
[QUOTE=gaggle;10234]Can I assume by using the modules system you are also granted plugin- and icon-paths, in addition to a new scripts path?[/QUOTE]
Yes, it adds script, plug-in, icon and prefs (I think) for each path defined in the modules file. It does not support shelves sadly, but we build those dynamically when Maya launches anyhow and delete them when Maya closes so there is no local version of those shelves on the users computer.
[QUOTE=gaggle;10234]The conflict you describe between userSetup.mel/py files sound really annoying though.[/QUOTE]
It’s just the userSetup.mel file which can get overridden by the user due to the way the MEL script paths work. But if defer execution works like you say then you won’t need a userSetup.mel in the modules path and it won’t be a problem. I have to try that tomorrow at work.
[QUOTE=gaggle;10234]Can you explain how you use sitecustomize for subfolders? Do you add the folders to sys.path? If so what are the advantages over sticking an init.py file in the folders so they becomes importable?[/QUOTE]
Yes, all I do is add all sub-folders in each modules designated script folder to sys.path. Being a relatively new Python user I don’t know if there are any advantages over using init.py. Still a lot to learn in this language and all the default functionality.
Yeah, given the size of CCP (The company has 5 or so studios scattered all over the world), it isn’t too surprising that the technology between the company’s various offices may be a bit out of synch. :):
If you don’t mind my asking, which CCP studio do you work at, Jon?
Yeah Wolfsong I think with Python we all have to continuously learn. This thread has spawned some notes of interest I have to pursue for myself too. Good discussion is good BTW I spotted you (and djTomServo too) on a YouTube Technical Artist channel, good stuff man.
And that’s funny with the uMen clients page Eevans, I’m in the Reykjavik office working on EVE Online.
Deferred execution worked perfect! So no more problem with user files. The users can do what they want locally now (besides removing the module file of course) and we will still have control of all the studio tools and interfaces.
I came to a system, everything is based on the user document editing maya.env scripts and plug-ins set up the path, I will call the method of the Stone Age way …
I like the idea of a proper launcher, we’re rolling out something similar these days (ours is more of a background service) and it shows a lot of promise. Excited to try it out.
The conflict you describe between userSetup.mel/py files sound really annoying though.
