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
