maya.standalone doesn't fill maya env vars
Chadrik
environment variables ( MAYA_APP_DIR, MAYA_SCRIPT_PATH, etc ) are not
set to their platform defaults. is there a way to trigger this in
standalone mode or will these have to be set manually?
-chad
H.N.(HARRY) ZHANG
Once you have maya standalone ready, try the following code,
import maya.mel as mel
mel.eval("getenv MAYA_SCRIPT_PATH")
you will get what you want.
Olivier Renouard
I think it's because os.environ is only update if you go through it to
modify env vars, as explained here :
http://docs.python.org/lib/os-procinfo.html
Wouldn't a os.getenv(varname) refresh it for a particular variable ? We
already parse Maya.env in mayainit (because otherwise the variable
settings happens too late for complete Python init), we could refresh
os.environ in the mayautils too.
Olivier
--
Olivier Renouard
Chadrik
ah, thanks. i see what's happening now.
like you said, if i initialize normally, the env's are available via
maya :
>>> import maya.standalone
>>> maya.standalone.initialize()
2008-07-21 16:38:18.531 Python[3519] LCC Scroll Enhancer loaded
>>> import maya.mel as mm
>>> mm.eval("getenv MAYA_SCRIPT_PATH")
'/Network/Servers/sv-user.luma-pictures.com/luma .....
but not in python:
>>> import os
>>> os.environ['MAYA_SCRIPT_PATH']
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/Applications/Autodesk/maya2008/Maya.app/Contents/Frameworks/
Python.framework/Versions/Current/lib/python2.5/UserDict.py", line 22,
in __getitem__
raise KeyError(key)
KeyError: 'MAYA_SCRIPT_PATH'
the reason i was so confused was because if i try to set os.environ in
python, i wipe out the maya-only env's too:
>>> os.environ[ 'MAYA_SCRIPT_PATH'] = os.environ.get( 'MAYA_SCRIPT_PATH', '') + os.path.pathsep + 'craptastic'
>>> mm.eval("getenv MAYA_SCRIPT_PATH")
':craptastic'
i think this should be considered a bug on maya's part.
for now i will add a fix for this to pymel.
-chad
On Jul 21, 4:03 pm, "H.N.(HARRY) ZHANG" <hnzh...@gmail.com> wrote:
> actually, they are there, but not accessible to python somehow.
>
> Once you have maya standalone ready, try the following code,
>
> import maya.mel as mel
> mel.eval("getenv MAYA_SCRIPT_PATH")
>
> you will get what you want.
>
>
> > i've noticed that when using mayapy and maya.standalone that the maya
> > environment variables ( MAYA_APP_DIR, MAYA_SCRIPT_PATH, etc ) are not
> > set to their platform defaults. is there a way to trigger this in
> > standalone mode or will these have to be set manually?
>
> > -chad
>
> --
> --------------------
> H.N.(HARRY) ZHANG
Chadrik
was just playing with that, but os.getenv does not seem to refresh
anything. returns None.
>>> os.getenv('MAYA_SCRIPT_PATH')
>>> mm.eval( "getenv MAYA_SCRIPT_PATH" )
maya/projects/default:/some/other/crap:/Network/Servers/sv-user.luma-
pictures.com/lumaUsers/chad/Library/Preferences/Autodesk/maya/2008/
scripts:/Network/Servers/sv-user.luma-pictures.com/lumaUsers/chad/
Library/....
>>> os.getenv('MAYA_SCRIPT_PATH')
>>>
a few other peculiarities to consider:
os.environ inherits variables from the shell just fine, but those
added by maya are not registered.
os.system('env') sees the maya variables
these hidden envs contain paths parsed from Maya.env, so using them in
conjunction with our own parsed information would cause dupes
anyway, i'm not sure how best to get these env's into os.environ.
we can:
1) call os.system( 'env') and transfer all envs over (this would
actually preclude the need for parsing Maya.env)
2) add hardwired calls to os.environ after parsing the Maya.env to
manually setup the default env values
neither is a particularly clean solution. the first potentially runs
the risk of setting varibles in os.environ that are not meant to be
there, while the second will require a lot of per-platform and per-
version maintainence.
-chad
On Jul 21, 4:36 pm, Olivier Renouard <o.renou...@attitude-studio.com>
wrote:
Chadrik
i have to admit i'm leaning toward #1.
the whole thing can be fixed by running the following code immediately
after initializing standalone
import os, commands, platform
exlude = ['SHLVL']
if platform.system() in [ 'Darwin', 'Linux' ]: envcmd = '/usr/bin/env'
else: envcmd = 'set'
for line in commands.getoutput(envcmd).split( '\n' ):
var, val = line.split('=')
if not var.startswith('_') and var not in exclude:
os.environ[var] = val
still have to test on windows. i'm sure i messed something up there.
i did some comparisons of the env's found thru /usr/bin/env versus
os.environ and i think this would be pretty safe to run. we can build
the exlude list as needed.
-chad
Olivier Renouard
Sounds good, must be careful that Maya's way of setting variables in
Maya.env is a bit peculiar too :
- some variables, if already set, won't be changed by a declaration in
Maya.env. Thus it sets them only if they were undefined (doesn't
overwrite).
- for the variables that are path, Maya adds the path declared in
Maya.env to them (because the syntax $PATH=$PATH:/usr/autodesk doesn't
work in Maya.env, I think to remember it just doesn't work on Linux and
it creates an endless loop on Windows)
- the reason for manually parsing Maya.env was so that it could be
parsed before initializing Maya. If you put there info like
LD_LIBRARY_PATH, it's too late to parse it after an init, as an init
won't be able to complete without properly setting this variable (that's
all the variables that are set before calling maya's executable in
Maya2008 shell script for instance). It is not strictly necessary but
thought it would be nice to regroup all variable declaration where
people are used to put them (Maya.env) so that you could start Maya by
just doing a "read Maya.env for the version of Maya that's being called,
call maya's executable".
This is I think what the startup shell Maya2008 should do instead of the
quite long bit of code that is actually in it, with a bunch of
overrides, custom declaration and layered addons. Besides, some custom
fixes (like lauching Maya with a different python interpreter or graphic
fixes like MAYA_MMSET_DEFAULT_XCURSOR 1 and XLIB_SKIP_ARGB_VISUALS 1on
linux) would require you to modify the Maya2008 script which is less
straightforward than allowing to place them with the rest in Maya.env.
Olivier
--
Olivier Renouard
Chadrik
perhaps the best solution is to do both. parse the Maya.env so that
it's available before standalone, then overwrite values in os.environ
immediately after initialization so that it's synced up.
i believe the peculiarities of setting values in the env is related to
variables which are expected to contain a single value versus those
that can contain a (semi)colon-separated list. for instance,
MAYA_PRESET_PATH (which can only be one directory) will not be
overwritten if set in Maya.env, while MAYA_SCRIPT_PATH will be
appended to, whether previously set or not.
"the reason for manually parsing Maya.env was so that it could be
parsed before initializing Maya. If you put there info like
LD_LIBRARY_PATH, it's too late to parse it after an init, as an init
won't be able to complete without properly setting this variable
(that's
all the variables that are set before calling maya's executable in
Maya2008 shell script for instance). "
late to set DYLD_LIBRARY_PATH or DYLD_FRAMEWORK_PATH. only by setting
them both in the shell prior to starting the interpreter can i get
maya.standalone to import. i haven't test linux or windows yet
(wasted too much time on this today already ), is the case different
there?
perhaps it is the same problem with other env's that you mentioned
(MAYA_MMSET_DEFAULT_XCURSOR,etc) where they must be set in the script
prior to executing maya binary, otherwise it is simply too late?
i think what is really needed is an env parsing system for maintaining
env files for any application -- essentially a Maya.env for anything.
we have recently made a tool like this, perhaps we'll open source it
as well.
-chad
On Jul 22, 12:25 am, Olivier Renouard <o.renou...@attitude-studio.com>
wrote:
Sebastian Thiel
According to my experience, variables like PATH on windows, LD_LIBRARY_PATH on linux. Probably its like that with more paths ( but I cannot tell yet ).
The XBMLANGPATH has to be set before starting maya or the interpreter on Linux, but can be set during MayaUI initialization in Windows ( which is particularly 'interesting' as your custom icons will just disappear on linux ).
In our environment I must support linux 64 and win32. On linux, I experienced the same LD_LIBRARY_PATH issues, and am currently setting this variable ( as well as LD_PRELOAD ) in the maya shell script directly.
On win32, this would work by having the PATH set to include the maya bin directory to support python standalone, appearing to be more stable with additional extensions .
Mayapy would work right away, but appears to be more shaky when it comes to extensions, probably because of tiny incompatabilities caused by the fact that these extensions have not been compiled against the modified version of maya's python interpreter.
The env-parsing system appears to be some kind of wrapper which is being started instead of the actual program, receiving instructions on how to setup the environment to finally start the actual program by swapping it into its own process space.
Today I would be very careful with such a tool, just because, in those days when used in a previous production, it turned out, that no program would properly start without the wrapper anymore - this is some kind of dependency one should use with great caution.
Cheers,
Sebastian
John Creson
I've bugged this and come up with a bit of a workaround...
The problem is that we are starting Maya inside of Python, instead of
in interactive where you are starting Python inside of Maya.
maya.standalone.initialize() should be doing more to transfer these
environment variables back up into Python.
One way I've worked around this goes like this:
On linux and mac:
./mayapy #double click the mayapy.exe on windows
import maya.standalone as ms
ms.initialize()
import os
os.system('csh') # use cmd on windows
./mayapy # just mayapy on windows
import maya.standalone as ms
ms.initilaize()
import os
os.environ.keys()
################
So, it's a bit strange, but here I am running Maya inside of Python
and then Python inside of Maya and then Maya inside of Python.
So there is a bit of a hit on the system. You might be able to save
the keys out and quit back into the first Maya inside of Python and
use os.environ[KEY] =maya.mel.eval('getenv KEY') for each KEY in keys.
barnabas79
way maya handles the maya.env is sort of odd, and it WOULD be nice to
have a more central place to set environment variables for maya), but
I'd be leery of creating a Maya.env that would only work if parsed by
pymel, and as chad points out, it would require a lot more specialized
code on our part. Perhaps if we want behavior similar to what you're
describing, we should allow the user to create an additional
pymel.env, which would be parsed either in addition to or in place of
the standard maya.env if pymel is loading?
- Paul
Chadrik
think it would be very cool to have a second "pymel-only" env as Paul
mentions, because we could extend our Maya.env parser to include env
var conditionals: ifdef, ifndef, ifeq, ifneq, else, endif. I've
wanted this for ages. i'm busy at the moment, who wants to give it a
go :)
-chad