sitecustomize.py help
David Shaw
I've setup a sitecustomize.py script which is located in a Maya module path to customise our Maya setup on launch
It basically queries a custom Maya environment variable located in the maya.env called "PYTHON_SITEPACKAGES" with
the following path: "D:/pipeline_tools/python/site-packages/"
(I've not used the PYTHONPATH on purpose so we can customise the packages for each version of maya without affecting the
standard paths - the script inserts them basically)
What it does is look at the path and add the "packages" from the folder name.
The folder has these package folders:
D:/pipeline_tools/python/site-packages/:
pymel_1.0.0rc2
pyodbc-2.1.7
I'm trying to extend what I have currently setup for our Maya 2010 setup so that can check the Maya version and tailor the
packages appropriately, for example Maya 2011 overriding pymel with newer versions without having to install it to every users machine.
If this sounds whacky and crazy please tell me :) I am new to python and its wonderful ways.
I've chosen the sitecustomize.py method because I can insert packages and only have to maintain one path in the Maya.env
instead of having to manage lots of .pth files etc etc
Anyway onto the problem, if I try and use maya.cmds in the sitecustomize.py I always get a warning(?) in the maya
output window: 'import site' failed; use -v for traceback
The sitecustomize.py is as follows:
import sys
import os
import maya.cmds as cmds
version = cmds.about(v=True)
path = os.environ.get ("PYTHON_SITEPACKAGES")
pathExists = os.path.exists(path)
if(pathExists):
sitePackages = os.listdir(path)
for package in sitePackages:
sitePath = os.path.join(path, package)
print '*** Inserting package: %s from path: %s' % (package, sitePath)
sys.path.insert(0,sitePath)
If I remove the version check the script process properly even though the import maya.cmds as cmds is still there.
Is it because the maya.cmds are not "active" properly at this early stage (only the output window is open)?
Any help would be appreciated :)
Thanks
Dave Shaw
Paul Molodowitch
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
David Shaw
Do you think the approach I am taking is feasible or practical?
How do you guys go about it?
Dave
--
http://groups.google.com/group/python_inside_maya
To unsubscribe, reply using "remove me" as the subject.
Ian Jones
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
Judah Baron
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.
Jo Jürgens
Ian Jones
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 <joju...@gmail.com>:
shawnpatapoff
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 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>
David Shaw
Thank you for your insights on the sitecustomize setup.
Bare with a new comer to python here and if anyone has the time to help explain the problem I get.
My intention was to just have it detect Maya's version and whether 32 or 64bit to load or not load appropriate packages.
In the case of Maya 2011 NOT install our server pymel package (although with Its 1.0 release today that may be moot)
[I assume inserting it before the internal version overrides it?]
But to my problem :).....
It seems if I try and access anything Maya related at this early stage bad things happen :)
Printing the lines Paul gave me to try when in the sitecustomize.py file gives the appropriate values I need
apiVerNum = MGlobal.apiVersion() and verString = MGlobal.mayaVersion()
(201100 and 2011 respectively)
If I use the MGlobal to query the maya version and do a check if its Maya 2011 so we do NOT install the pymel package for that version of Maya
I get the following error:
from pymel.all import *
# Error: AssertionError: assert hasattr(maya.utils, 'shellLogHandler'), "If you manually installed pymel, ensure " \: If you manually installed pymel, ensure that pymel comes before Maya's site-packages directory on PYTHONPATH / sys.path. See pymel docs for more info. #
If you look at the path outputs below pymel does show before the Maya packages
But if I comment out the anything that calls Maya and replace it with mayaVersion = '2011' pymel imports just fine.
The path output is identical.
Post Path: D:\pipeline_tools\python\site-packages\pyodbc-2.1.7
Post Path: D:\pipeline_tools\python\site-packages\pymel_1.0.0rc2
Post Path: I:\Program Files (x86)\Autodesk\Maya2010\bin
Post Path: I:\Program Files (x86)\Autodesk\Maya2010\bin\python26.zip
Post Path: I:\Program Files (x86)\Autodesk\Maya2010\Python\DLLs
Post Path: I:\Program Files (x86)\Autodesk\Maya2010\Python\lib
Post Path: I:\Program Files (x86)\Autodesk\Maya2010\Python\lib\plat-win
Post Path: I:\Program Files (x86)\Autodesk\Maya2010\Python\lib\lib-tk
Post Path: I:\Program Files (x86)\Autodesk\Maya2010\Python
Post Path: I:\Program Files (x86)\Autodesk\Maya2010\Python\lib\site-packages
This is the sitecustomeize.py that doesn't work [excuse any noob things if I am doing things the long way]
import sys
import os
import re
from maya.OpenMaya import MGlobal
for p in sys.path: print ('Pre Path: ' + p)
apiVerNum = MGlobal.apiVersion()
verString = MGlobal.mayaVersion()
mayaVersion = str(verString)
path = os.environ.get ("PYTHON_SITEPACKAGES")
if(os.path.exists(path)):
sitePackages = os.listdir(path)
packagesToInsert = sitePackages[:] #duplicate the list so we can remove any packages we don't want to insert
for package in sitePackages:
if mayaVersion == '2011':
pymelMatch = re.match('pymel', package)
if pymelMatch:
packagesToInsert.remove(package)
for insertPackage in packagesToInsert:
sitePath = os.path.join(path, insertPackage)
realPath = os.path.realpath(sitePath)
print '*** Inserting package: %s from path: %s' % (insertPackage, realPath)
sys.path.insert(0,realPath)
else:
print "DEV: Site packages path does not exist in Maya.env - skipping"
for p in sys.path: print ('Post Path: ' + p)
This is the sitecustomeize.py that does work [excuse any noob things if I am doing things the long way]
import sys
import os
import re
#from maya.OpenMaya import MGlobal
for p in sys.path: print ('Pre Path: ' + p)
#apiVerNum = MGlobal.apiVersion()
#verString = MGlobal.mayaVersion()
mayaVersion = '2011'
path = os.environ.get ("PYTHON_SITEPACKAGES")
if(os.path.exists(path)):
sitePackages = os.listdir(path)
packagesToInsert = sitePackages[:] #duplicate the list so we can remove any packages we don't want to insert
for package in sitePackages:
if mayaVersion == '2011':
pymelMatch = re.match('pymel', package)
if pymelMatch:
packagesToInsert.remove(package)
for insertPackage in packagesToInsert:
sitePath = os.path.join(path, insertPackage)
realPath = os.path.realpath(sitePath)
print '*** Inserting package: %s from path: %s' % (insertPackage, realPath)
sys.path.insert(0,realPath)
else:
print "DEV: Site packages path does not exist in Maya.env - skipping"
for p in sys.path: print ('Post Path: ' + p)
with the following folders in D:\pipeline_tools\python\site-packages\:
pymel_1.0.0rc2
pyodbc-2.1.7
Anyway hopefully all that makes some sense and points the way to why it didnt work :)
Dave
Chad Dombrova
David Shaw
The D:\pipeline_tools\python\site-packages\ folder only has pymel and pyodbc folders in it.
The rest of the default Maya side of things comes from the standard install directories.
The sitecustomize.py file is located in D:\pipeline_tools\maya\modules\thq_python\scripts
and is added to the path by the standard maya module path system.
Dave
David Shaw
Doh!
Dave