Hey, What I've done here to support different scripts, plug-in etc is to write a Maya launcher in PyQt. Essentially the user gets a UI with several different flavors of Maya to choose from. Our flavors are just different projects. When the user clicks, a new thread is spawned with a blank environment. I then populate the environment based on the selection. This give me absolute control on where maya will look at things as I'm controlling the environments vars it will be looking at.
So far it seems to be working pretty well. Cheers, -Shawn On Apr 12, 8:39 am, Ian Jones <i...@ambientdivide.com> wrote: > My understanding is that sitecustomize.py is still supported, just not > in all the ways it used to be prior to version 2.5. I'm using it with > version 2.6 right now in fact. > > The major change in 2.5 related to sitecustomize.py is that it must be > on the original pythonpath in order for it to be executed. Prior to > 2.5 you were able to save sitecustomize.py in the current working > directory and python would execute it. This is because the cwd is now > added to the path much later (and after the site module loads). > > This recipe seems to support this understanding: > > http://code.activestate.com/recipes/552729/ > > That all said projects/packages that were using it via the no longer > supported methods could easily break so YMMV. > > 2010/4/12 Jo Jürgens <jojurg...@gmail.com>: > > > Just be aware that sitecustomize.py is unsupported by Python since Python 25 > > and may cause problems with other modules. Ive had it break Django or Pylons > > (dont remember which one), so I stopped using it. > > > On Mon, Apr 12, 2010 at 8:41 AM, Judah Baron <judah.ba...@gmail.com> wrote: > > >> We use a minimal sitecustomize.py, but it's intentionally minimal - it > >> just copies data from a buffer var into PYTHONPATH. We don't use the > >> maya.env file at all because we need all of our tools to run from > >> similarly configured environments. We do this with data from xml > >> files. We also do not use the system PYTHONPATH var because we need to > >> explicitly define what should be running and from where - we don't > >> want to inherit someone's 3.0 install, for instance. > > >> The other related thing we do that may be of interest to you is to > >> call the python interpreter explicitly, rather than relying on some os > >> level association, which might give you the wrong one. We have a stand > >> alone application that runs most of our tools. When a user runs Maya, > >> or any tool, this stand alone app builds an environment for it and > >> then runs it. We don't absolutely need to build the environment each > >> time, as it would be inherited from the calling process, but we wanted > >> the option of overloading some settings. We keep all of our tools, > >> including Maya, in our Perforce depot. Aside from getting around > >> having to install it, this means we know exactly where it is, so we > >> can call the correct mayapy directly. > > >> At any rate, what you are describing sounds reasonable, but I would > >> advise limiting the content of sitecustomize to site customization > >> only. Not only will your cmds problem go away, but you will a system > >> that is easier to troubleshoot. > > >> On Sun, Apr 11, 2010 at 10:05 PM, Ian Jones <i...@ambientdivide.com> wrote: > >> > I use a sitecustomize.py for our general python packages and a > >> > seperate usersetup.py (right beside the sitecustomize.py) to handle > >> > specific items for maya. > > >> > It cuts down the sitecustomize into more manageable pieces and seems > >> > to be working out well for us. > > >> > Ian > > >> > On Sun, Apr 11, 2010 at 8:06 PM, David Shaw <flopp...@gmail.com> wrote: > >> >> Thank you Paul, much appreciated. > > >> >> Do you think the approach I am taking is feasible or practical? > > >> >> How do you guys go about it? > > >> >> Dave > > >> >> On Mon, Apr 12, 2010 at 1:55 AM, Paul Molodowitch <elron...@gmail.com> > >> >> wrote: > > >> >>> In a nutshell - yes, it's probably failing because cmds hasn't been > >> >>> properly initialized yet. > >> >>> The deal with maya.cmds is that's it's actually an empty module, whose > >> >>> contents are filled in during maya's initialization process. That's > >> >>> why you were able to import it, but not call anything useful within > >> >>> it. > >> >>> To query your maya version even before maya.cmds has been populated, I > >> >>> recommend using MGlobal: > > >> >>> from maya.OpenMaya import MGlobal > > >> >>> apiVerNum = MGlobal.apiVersion() > >> >>> verString = MGlobal.mayaVersion() > > >> >>> - Paul > > >> >>> -- > >> >>>http://groups.google.com/group/python_inside_maya > > >> >>> To unsubscribe, reply using "remove me" as the subject. > > >> >> -- > >> >>http://groups.google.com/group/python_inside_maya > > >> > -- > >> >http://groups.google.com/group/python_inside_maya > > >> -- > >>http://groups.google.com/group/python_inside_maya > > > -- > >http://groups.google.com/group/python_inside_maya > > -- http://groups.google.com/group/python_inside_maya
