From: "Mr. Daniel Browne" <dbrowne@(email surpressed)>
Subject: CentOS 6 Python error
   Date: Mon, 11 Mar 2013 16:27:47 -0400

We just upgraded to CentOS 6 and now none of my submit scripts can be called from within maya. They fail with the following error:

Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "/EEP/Tools/Settings/rush/rushscripts_v102.42a9/submit-maya-python/submit-maya2012.py", line 18, in <module>
    import os,sys,re,glob,shutil,time,Rush
ImportError: No module named os

So far setting the PYTHONHOME var has not had an effect. I can't see exactly what the environment conflict comes from.


----------
Dan "Doc" Browne
System Administrator
Evil Eye Pictures

dbrowne@(email surpressed)
Office: (415) 777-0666 x105

Hi Dan,

	Hmm, try making a simple python script that looks like this:

import os,sys
print >> sys.stderr, "Hello, stderr"

	Does that load and run OK from within maya, or do you get those
	same module errors?

	If you get an error with that, then something much bigger is being
	broken.. might be just a PATH problem of some kind, as python looks
	at the PATH as well as the PYTHONPATH and PYTHONHOME.



On 03/11/13 13:27, Mr. Daniel Browne wrote:
> We just upgraded to CentOS 6 and now none of my submit scripts can be =
> called from within maya. They fail with the following error:
> 
> Could not find platform independent libraries <prefix>
> Could not find platform dependent libraries <exec_prefix>
> Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
> 'import site' failed; use -v for traceback
> Traceback (most recent call last):
>   File =
> "/EEP/Tools/Settings/rush/rushscripts_v102.42a9/submit-maya-python/submit-=
> maya2012.py", line 18, in <module>
>     import os,sys,re,glob,shutil,time,Rush
> ImportError: No module named os
> 
> So far setting the PYTHONHOME var has not had an effect. I can't see =
> exactly what the environment conflict comes from.


-- 
Greg Ercolano, erco@(email surpressed)
Seriss Corporation
Rush Render Queue, http://seriss.com/rush/

Tel: (Tel# suppressed)ext.23
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)

unsubscribe


On Mar 11, 2013, at 3:30 PM, Greg Ercolano <erco@(email surpressed)>
 wrote:

> [posted to rush.general]
> 
> Hi Dan,
> 
> 	Hmm, try making a simple python script that looks like this:
> 
> import os,sys
> print >> sys.stderr, "Hello, stderr"
> 
> 	Does that load and run OK from within maya, or do you get those
> 	same module errors?
> 
> 	If you get an error with that, then something much bigger is being
> 	broken.. might be just a PATH problem of some kind, as python looks
> 	at the PATH as well as the PYTHONPATH and PYTHONHOME.
> 
> 
> 
> On 03/11/13 13:27, Mr. Daniel Browne wrote:
>> We just upgraded to CentOS 6 and now none of my submit scripts can be =
>> called from within maya. They fail with the following error:
>> 
>> Could not find platform independent libraries <prefix>
>> Could not find platform dependent libraries <exec_prefix>
>> Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
>> 'import site' failed; use -v for traceback
>> Traceback (most recent call last):
>>  File =
>> "/EEP/Tools/Settings/rush/rushscripts_v102.42a9/submit-maya-python/submit-=
>> maya2012.py", line 18, in <module>
>>    import os,sys,re,glob,shutil,time,Rush
>> ImportError: No module named os
>> 
>> So far setting the PYTHONHOME var has not had an effect. I can't see =
>> exactly what the environment conflict comes from.
> 
> 
> -- 
> Greg Ercolano, erco@(email surpressed)
> Seriss Corporation
> Rush Render Queue, http://seriss.com/rush/
> 
> Tel: +1 626-576-0010 ext.23
> Fax: +1 626-576-0020
> Cel: +1 310-266-8906
> 

On 03/11/13 15:35, Rob Groome wrote:
> [posted to rush.general]
> unsubscribe

	Ha, OK Rob, done.


-- 
Greg Ercolano, erco@(email surpressed)
Seriss Corporation
Rush Render Queue, http://seriss.com/rush/

Tel: (Tel# suppressed)ext.23
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)

Same result with the test script.


On Mar 11, 2013, at 3:30 PM, Greg Ercolano wrote:

[posted to rush.general]

Hi Dan,

	Hmm, try making a simple python script that looks like this:

import os,sys
print >> sys.stderr, "Hello, stderr"

	Does that load and run OK from within maya, or do you get those
	same module errors?

	If you get an error with that, then something much bigger is being
	broken.. might be just a PATH problem of some kind, as python looks
	at the PATH as well as the PYTHONPATH and PYTHONHOME.



On 03/11/13 13:27, Mr. Daniel Browne wrote:
> We just upgraded to CentOS 6 and now none of my submit scripts can be =
> called from within maya. They fail with the following error:
> 
> Could not find platform independent libraries <prefix>
> Could not find platform dependent libraries <exec_prefix>
> Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
> 'import site' failed; use -v for traceback
> Traceback (most recent call last):
>  File =
> "/EEP/Tools/Settings/rush/rushscripts_v102.42a9/submit-maya-python/submit-=
> maya2012.py", line 18, in <module>
>    import os,sys,re,glob,shutil,time,Rush
> ImportError: No module named os
> 
> So far setting the PYTHONHOME var has not had an effect. I can't see =
> exactly what the environment conflict comes from.


-- 
Greg Ercolano, erco@(email surpressed)
Seriss Corporation
Rush Render Queue, http://seriss.com/rush/

Tel: (Tel# suppressed)ext.23
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)


----------
Dan "Doc" Browne
System Administrator
Evil Eye Pictures

dbrowne@(email surpressed)
Office: (415) 777-0666 x105

On 03/11/13 15:50, Mr. Daniel Browne wrote:
> Same result with the test script.

	OK, so kinda up to you on how to fix the maya python environment.

	Sounds like some environment variable is preventing maya from
	accessing its own os.py module (which should be a path withing
	the autodesk/maya directory, something like ./lib/python*/os.py)

	Might want to take this to the autodesk support or autodesk forums
	if you're sure it's not environment settings your own maya customizations
	have tweaked.

	Check if you have any custom maya mel or python scripts that change
	the PATH or PYTHONPATH or PYTHONHOME that's preventing it from finding
	its own os modules.


-- 
Greg Ercolano, erco@(email surpressed)
Seriss Corporation
Rush Render Queue, http://seriss.com/rush/

Tel: (Tel# suppressed)ext.23
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)

I've opened a ticket with autodesk; I could swear I hadn't encountered this issue before.

The Rush window will show when I set PYTHONHOME to /usr/autodesk/maya2013-x64, but I get the error again when I press the submit button.


On Mar 11, 2013, at 4:28 PM, Greg Ercolano wrote:

[posted to rush.general]

On 03/11/13 15:50, Mr. Daniel Browne wrote:
> Same result with the test script.

	OK, so kinda up to you on how to fix the maya python environment.

	Sounds like some environment variable is preventing maya from
	accessing its own os.py module (which should be a path withing
	the autodesk/maya directory, something like ./lib/python*/os.py)

	Might want to take this to the autodesk support or autodesk forums
	if you're sure it's not environment settings your own maya customizations
	have tweaked.

	Check if you have any custom maya mel or python scripts that change
	the PATH or PYTHONPATH or PYTHONHOME that's preventing it from finding
	its own os modules.


-- 
Greg Ercolano, erco@(email surpressed)
Seriss Corporation
Rush Render Queue, http://seriss.com/rush/

Tel: (Tel# suppressed)ext.23
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)


----------
Dan "Doc" Browne
System Administrator
Evil Eye Pictures

dbrowne@(email surpressed)
Office: (415) 777-0666 x105

On 03/11/13 20:30, Mr. Daniel Browne wrote:
> [posted to rush.general]
> 
> I've opened a ticket with autodesk; I could swear I hadn't encountered =
> this issue before.
> 
> The Rush window will show when I set PYTHONHOME to =
> /usr/autodesk/maya2013-x64, but I get the error again when I press the =
> submit button.

	Great.

	BTW, I'm assuming if you try running that hello script (or for that matter
	the rush submit script) from /OUTSIDE/ maya, it works normally.. and that
	it's only /inside/ maya it doesn't work (as per the original post).

	With autodesk, focus on just trying to get the simple hello program
	to work without erroring out on the "import os,sys" line. Once you fix
	that, the rush stuff should work too.

	The hello example is a good way of replicating the problem for Autodesk
	support without involving any of the rush stuff.

	That 'import os' line should not be failing with that error you sent me,

ImportError: No module named os

	..as /that/ is a big problem for any python script.

	My guess is something changed in the environment that is preventing
	maya's python from finding the 'import os' module. Probably something
	in a customized maya startup file (MEL or python) that is changing
	the PATH or PYTHONPATH in such a way that maya's internal version of
	python can no longer find its own 'import os' module.

	It might even be other seemingly unrelated variables like
	LD_LIBRARY_PATH, or some such. Or perhaps even a file system problem,
	or problem with the linux upgrade scripts that might have messed up
	Maya's own version of python. (Though if it did that, I'd think Maya
	wouldn't open up at all, as I'm sure it probably uses the os module
	itself heavily)


-- 
Greg Ercolano, erco@(email surpressed)
Seriss Corporation
Rush Render Queue, http://seriss.com/rush/

Tel: (Tel# suppressed)ext.23
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)

I just came across an article relating to this issue on the autodesk site (from a google search).

http://usa.autodesk.com/adsk/servlet/ps/dl/item?siteID=123112&id=13375416&linkID=9242258

However, though it finds the os module, it now cannot find the time module which theoretically should be in the same path. Here are my exports I prepended to the rest of the os.system() call in Maya:

export PYTHONHOME=/usr/;export PYTHONPATH="/usr/lib64/python2.6/:$PYTHONPATH"


On Mar 11, 2013, at 10:38 PM, Greg Ercolano wrote:

[posted to rush.general]

On 03/11/13 20:30, Mr. Daniel Browne wrote:
> [posted to rush.general]
> 
> I've opened a ticket with autodesk; I could swear I hadn't encountered =
> this issue before.
> 
> The Rush window will show when I set PYTHONHOME to =
> /usr/autodesk/maya2013-x64, but I get the error again when I press the =
> submit button.

	Great.

	BTW, I'm assuming if you try running that hello script (or for that matter
	the rush submit script) from /OUTSIDE/ maya, it works normally.. and that
	it's only /inside/ maya it doesn't work (as per the original post).

	With autodesk, focus on just trying to get the simple hello program
	to work without erroring out on the "import os,sys" line. Once you fix
	that, the rush stuff should work too.

	The hello example is a good way of replicating the problem for Autodesk
	support without involving any of the rush stuff.

	That 'import os' line should not be failing with that error you sent me,

ImportError: No module named os

	..as /that/ is a big problem for any python script.

	My guess is something changed in the environment that is preventing
	maya's python from finding the 'import os' module. Probably something
	in a customized maya startup file (MEL or python) that is changing
	the PATH or PYTHONPATH in such a way that maya's internal version of
	python can no longer find its own 'import os' module.

	It might even be other seemingly unrelated variables like
	LD_LIBRARY_PATH, or some such. Or perhaps even a file system problem,
	or problem with the linux upgrade scripts that might have messed up
	Maya's own version of python. (Though if it did that, I'd think Maya
	wouldn't open up at all, as I'm sure it probably uses the os module
	itself heavily)


-- 
Greg Ercolano, erco@(email surpressed)
Seriss Corporation
Rush Render Queue, http://seriss.com/rush/

Tel: (Tel# suppressed)ext.23
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)


----------
Dan "Doc" Browne
System Administrator
Evil Eye Pictures

dbrowne@(email surpressed)
Office: (415) 777-0666 x105

On 03/12/13 12:50, Mr. Daniel Browne wrote:
> http://usa.autodesk.com/adsk/servlet/ps/dl/item?siteID=123112&id=13375416&linkID=9242258

	Ahh, I see, when it comes to executing /external/ python scripts, maya's
	python environment variables are probably being passed on to the OS's version
	of python, confusing it.

	It makes sense now why an OS upgrade broke stuff; probably before the upgrade
	the unix OS's version of python was the same, or close enough to maya's own
	version of python that the maya python environment settings worked OK for the
	OS's python.

	But when you upgraded the OS, the OS's python upgraded too, perhaps to a version
	of python not compatible with Maya's internal python.

	So yes, that article about using maya's python os.system() call to run /external/
	python scripts is somewhat relevant because any python related environment variables
	maya has set to point to its own python installation would be bad for the OS's
	version of python (which is probably different from maya's, after the OS upgrade)

	Sounds like the simple solution is to bracket all calls to os.system() with code
	that first preserves the current environment variables, then changes the PYTHONPATH
	(and whatever else) to what the OS's version of python needs. e.g.

ppsave = os.environ["PYTHONPATH"]
os.system(your_cmd)
os.environ["PYTHONPATH"] = ppsave

	You can probably make that a function so that you don't have to include
	that code every time you use os.system().. just use your function instead.

	You may find you need to change other environment variables too
	(like PATH, PYTHONHOME, perhaps others).

	I'd suggest comparing the output of:

		printenv|sort > /tmp/unix.env

	..to running that same command from /within/ maya, e.g.

		os.system("printenv|sort > /tmp/maya.env")

	..and then check to see what PATH and PYTHON* variables are different..
	then be sure to modify those with the bracketing code defined above.

	Thing is, other python commands that invoke external python scripts
	might need this bracketing code as well; os.popen(), subprocess.Popen(),
	just to name a few.

	Arguably maya should protect us from having to worry about this
	by doing the bracketing code itself.. but I can see where that would
	get hairy from Autodesk's point of view..

-- 
Greg Ercolano, erco@(email surpressed)
Seriss Corporation
Rush Render Queue, http://seriss.com/rush/

Tel: (Tel# suppressed)ext.23
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)

On 03/12/13 13:25, Greg Ercolano wrote:
> 	Sounds like the simple solution is to bracket all calls to os.system() with code
> 	that first preserves the current environment variables, then changes the PYTHONPATH
> 	(and whatever else) to what the OS's version of python needs. e.g.
> 
> ppsave = os.environ["PYTHONPATH"]
> os.system(your_cmd)
> os.environ["PYTHONPATH"] = ppsave

	Oops, forgot to add a line that /changes/ the PYTHONPATH to
	whatever you want PYTHONPATH to be when your_cmd is running.

	Also, it might be best to make that code a bit more robust,
	protecting it from a situation where PYTHONPATH /isn't/ set, e.g.

# SAVE OLD PYTHONPATH
if os.environ.has_key("PYTHONPATH"): ppsave = os.environ["PYTHONPATH"]
else:                                ppsave = None

# CHANGE TO WHAT OS WANTS
os.environ["PYTHONPATH"] = "/what/you/want"

# INVOKE UNIX COMMAND
os.system(your_cmd)

# RESTORE PYTHONPATH
if ppsave != None: os.environ["PYTHONPATH"] = ppsave
else:              del os.environ["PYTHONPATH"]

	This way you can safely set PYTHONPATH just for your unix command
	to run, then it changes it back so that maya has what it needs to
	run normally.

	Note: in my case, my OS's version of python works well with PYTHONPATH
	completely unset. If that's what yours needs too, then change the above
	line below 'CHANGE TO WHAT OS WANTS' to instead be:

# CHANGE TO WHAT OS WANTS
if os.environ.has_key("PYTHONPATH"): del os.environ["PYTHONPATH"]

	This will make sure that variable is /unset/ before calling os.system()
	so that the OS version of python won't see it set, and will use its own
	defaults. (Probably better than trying to guess what those defaults are)

-- 
Greg Ercolano, erco@(email surpressed)
Seriss Corporation
Rush Render Queue, http://seriss.com/rush/

Tel: (Tel# suppressed)ext.23
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)

The solution I ultimately found was to set 

export PYTHONHOME=/usr/autodesk/maya2013-x64

within maya's os.system() call before the external python script is executed, then within the script un-set it or set it back to /usr/ before the rest of the imports are executed. None of the PYTHONPATH related solutions worked.


On Mar 12, 2013, at 1:45 PM, Greg Ercolano wrote:

[posted to rush.general]

On 03/12/13 13:25, Greg Ercolano wrote:
> 	Sounds like the simple solution is to bracket all calls to os.system() with code
> 	that first preserves the current environment variables, then changes the PYTHONPATH
> 	(and whatever else) to what the OS's version of python needs. e.g.
> 
> ppsave = os.environ["PYTHONPATH"]
> os.system(your_cmd)
> os.environ["PYTHONPATH"] = ppsave

	Oops, forgot to add a line that /changes/ the PYTHONPATH to
	whatever you want PYTHONPATH to be when your_cmd is running.

	Also, it might be best to make that code a bit more robust,
	protecting it from a situation where PYTHONPATH /isn't/ set, e.g.

# SAVE OLD PYTHONPATH
if os.environ.has_key("PYTHONPATH"): ppsave = os.environ["PYTHONPATH"]
else:                                ppsave = None

# CHANGE TO WHAT OS WANTS
os.environ["PYTHONPATH"] = "/what/you/want"

# INVOKE UNIX COMMAND
os.system(your_cmd)

# RESTORE PYTHONPATH
if ppsave != None: os.environ["PYTHONPATH"] = ppsave
else:              del os.environ["PYTHONPATH"]

	This way you can safely set PYTHONPATH just for your unix command
	to run, then it changes it back so that maya has what it needs to
	run normally.

	Note: in my case, my OS's version of python works well with PYTHONPATH
	completely unset. If that's what yours needs too, then change the above
	line below 'CHANGE TO WHAT OS WANTS' to instead be:

# CHANGE TO WHAT OS WANTS
if os.environ.has_key("PYTHONPATH"): del os.environ["PYTHONPATH"]

	This will make sure that variable is /unset/ before calling os.system()
	so that the OS version of python won't see it set, and will use its own
	defaults. (Probably better than trying to guess what those defaults are)

-- 
Greg Ercolano, erco@(email surpressed)
Seriss Corporation
Rush Render Queue, http://seriss.com/rush/

Tel: (Tel# suppressed)ext.23
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)


----------
Dan "Doc" Browne
System Administrator
Evil Eye Pictures

dbrowne@(email surpressed)
Office: (415) 777-0666 x105

On 03/12/13 13:51, Mr. Daniel Browne wrote:
> The solution I ultimately found was to set:
> export PYTHONHOME=/usr/autodesk/maya2013-x64

I see.. so it sounds like just that variable was the problem.

But, hmm, isn't that telling the OS's version of python
to use autodesk's version of python, and thus a potential
for crashing python due to possibly incompatible modules?

I think it'd be safer to simply unset the PYTHONHOME variable
so that the OS's python uses its own defaults, e.g.

	os.system("unset PYTHONHOME; python /your/script.py")

Or, using the longer form technique I wrote earlier, the only
benefit being it should work across platforms, and can be expanded
to handle other variables if, for instance, the Windows version of
python has other settings that are needed:

---- snip
import os
def MySystem(cmd):
    # SAVE OLD PYTHONHOME
    if os.environ.has_key("PYTHONHOME"): phsave = os.environ["PYTHONHOME"]
    else:                                phsave = None

    # CHANGE TO WHAT OS WANTS
    if os.environ.has_key("PYTHONHOME"): del os.environ["PYTHONHOME"]

    # INVOKE UNIX COMMAND
    os.system(cmd)

    # RESTORE PYTHONPATH
    if phsave != None: os.environ["PYTHONHOME"] = phsave
---- snip

So if you define that inside maya's python environment,
you can then run unix commands with:

	MySystem(your_unix_command)

..and external calls to python will be protected from maya's PYTHONHOME.

-- 
Greg Ercolano, erco@(email surpressed)
Seriss Corporation
Rush Render Queue, http://seriss.com/rush/

Tel: (Tel# suppressed)ext.23
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)

I'll try the unset method; actually that is what Maya is supposed to be doing for you but seeming isn't. Maya2012 for instance sets PYTHONHOME to /u/mayabld/Python-2.6.4/pybuild


On Mar 12, 2013, at 2:17 PM, Greg Ercolano wrote:

[posted to rush.general]

On 03/12/13 13:51, Mr. Daniel Browne wrote:
> The solution I ultimately found was to set:
> export PYTHONHOME=/usr/autodesk/maya2013-x64

I see.. so it sounds like just that variable was the problem.

But, hmm, isn't that telling the OS's version of python
to use autodesk's version of python, and thus a potential
for crashing python due to possibly incompatible modules?

I think it'd be safer to simply unset the PYTHONHOME variable
so that the OS's python uses its own defaults, e.g.

	os.system("unset PYTHONHOME; python /your/script.py")

Or, using the longer form technique I wrote earlier, the only
benefit being it should work across platforms, and can be expanded
to handle other variables if, for instance, the Windows version of
python has other settings that are needed:

---- snip
import os
def MySystem(cmd):
   # SAVE OLD PYTHONHOME
   if os.environ.has_key("PYTHONHOME"): phsave = os.environ["PYTHONHOME"]
   else:                                phsave = None

   # CHANGE TO WHAT OS WANTS
   if os.environ.has_key("PYTHONHOME"): del os.environ["PYTHONHOME"]

   # INVOKE UNIX COMMAND
   os.system(cmd)

   # RESTORE PYTHONPATH
   if phsave != None: os.environ["PYTHONHOME"] = phsave
---- snip

So if you define that inside maya's python environment,
you can then run unix commands with:

	MySystem(your_unix_command)

..and external calls to python will be protected from maya's PYTHONHOME.

-- 
Greg Ercolano, erco@(email surpressed)
Seriss Corporation
Rush Render Queue, http://seriss.com/rush/

Tel: (Tel# suppressed)ext.23
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)


----------
Dan "Doc" Browne
System Administrator
Evil Eye Pictures

dbrowne@(email surpressed)
Office: (415) 777-0666 x105

On 03/12/13 14:26, Mr. Daniel Browne wrote:
> [posted to rush.general]
> 
> I'll try the unset method; actually that is what Maya is supposed to be =
> doing for you but seeming isn't. Maya2012 for instance sets PYTHONHOME =
> to /u/mayabld/Python-2.6.4/pybuild

	Yes, I think the unset is worth a try, at least on unix platforms
	that should work, as it's bourne shell syntax. (DOS has different syntax)

	It's best to make sure the OS version of python doesn't try to read
	its base modules (like os, sys, subprocess..) from a different version
	of python (like maya's own python), because some modules use binaries
	internally, and python could crash badly if it loads modules that were
	compiled with a different ABI.

-- 
Greg Ercolano, erco@(email surpressed)
Seriss Corporation
Rush Render Queue, http://seriss.com/rush/

Tel: (Tel# suppressed)ext.23
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)

The unset method does not work. I get the impression the GUI is being displayed using maya's internal python, but then subsequent calls to the script require PYTHONHOME to be set to /usr otherwise they will fail as they are running outside maya's environment.

The PYTHONPATH solution suggested by the autodesk page doesn't resolve it either. What still puzzles me is why I didn't have this problem before; I've had a test machine running CentOS 6 for a while now and I swear the submits were working just fine before.
I even tried the CentOS 6.4 update that came out yesterday and there was no difference.


On Mar 12, 2013, at 2:49 PM, Greg Ercolano wrote:

[posted to rush.general]

On 03/12/13 14:26, Mr. Daniel Browne wrote:
> [posted to rush.general]
> 
> I'll try the unset method; actually that is what Maya is supposed to be =
> doing for you but seeming isn't. Maya2012 for instance sets PYTHONHOME =
> to /u/mayabld/Python-2.6.4/pybuild

	Yes, I think the unset is worth a try, at least on unix platforms
	that should work, as it's bourne shell syntax. (DOS has different syntax)

	It's best to make sure the OS version of python doesn't try to read
	its base modules (like os, sys, subprocess..) from a different version
	of python (like maya's own python), because some modules use binaries
	internally, and python could crash badly if it loads modules that were
	compiled with a different ABI.

-- 
Greg Ercolano, erco@(email surpressed)
Seriss Corporation
Rush Render Queue, http://seriss.com/rush/

Tel: (Tel# suppressed)ext.23
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)


----------
Dan "Doc" Browne
System Administrator
Evil Eye Pictures

dbrowne@(email surpressed)
Office: (415) 777-0666 x105

On 03/12/13 15:02, Mr. Daniel Browne wrote:
> The unset method does not work. I get the impression the GUI is being =
> displayed using maya's internal python, but then subsequent calls to the =
> script require PYTHONHOME to be set to /usr otherwise they will fail as =
> they are running outside maya's environment.

	Weird. I can't help but think that the PATH might be being
	used here as well.. I know python can be influenced by the PATH,
	so you may want to check that closely as well.

> The PYTHONPATH solution suggested by the autodesk page doesn't resolve =
> it either. What still puzzles me is why I didn't have this problem =
> before; I've had a test machine running CentOS 6 for a while now and I =
> swear the submits were working just fine before.
> I even tried the CentOS 6.4 update that came out yesterday and there was =
> no difference.

	I'd compare the environments between the two machines to see
	if there's something obvious.

	I like to use 'printenv | sort > /tmp/foo.txt' to save the environment
	settings; run that on both machines from within maya, and then use a
	program like diff, xxdiff or 'vi -d' to compare the two files to see
	what's different.

	You may find you want to break out the PATH variable separately
	into separate lines at each ':' to see what's different and possibly
	track down if that difference is the issue.


-- 
Greg Ercolano, erco@(email surpressed)
Seriss Corporation
Rush Render Queue, http://seriss.com/rush/

Tel: (Tel# suppressed)ext.23
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)

	OK Dan, just tested with Maya 2013 + Scientific Linux 6.3
	and could replicate the error, and work around it.


	REPLICATION
	-----------
	Created /tmp/foo.py with the contents:

import os,sys
print >> sys.stderr, "Hello world."


	Opened a fresh install of Maya 2013, and in the Maya python editor ran:

import os
os.system("python /tmp/foo.py")

	..which gave the following error in the unix terminal
	that I invoked Maya from:

--- snip
Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "/tmp/foo.py", line 1, in <module>
    import os,sys
ImportError: No module named os
--- snip

	ANALYSIS
	--------

	I noticed PYTHONPATH and LD_LIBRARY_PATH both set in a way that I thought
	would break the OS version of python.

	SOLUTION
	--------
	So I modified the above command to unset those two variables
	as part of the command being run:

os.system("unset PYTHONPATH; unset LD_LIBRARY_PATH; python /tmp/foo.py")

	..and that worked fine.. printed 'Hello world.' in the terminal,
	and returned '0' as the exit code.

	With that working, I was able to include those 'unset' commands
	to run the rush submit_maya.py python script as well and submit
	a job successfully:

os.system("unset PYTHONPATH; unset LD_LIBRARY_PATH; python /eagle/net/rushscripts-103/python/submit_maya.py")

	HTH.

-- 
Greg Ercolano, erco@(email surpressed)
Seriss Corporation
Rush Render Queue, http://seriss.com/rush/

Tel: (Tel# suppressed)ext.23
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)

Hmm, I hadn't played around with the LD_LIBRARY_PATH. Well as long as it works one way or the other I'm satisfied, I just wish I knew why it appeared now all of a sudden.



On Mar 12, 2013, at 5:38 PM, Greg Ercolano wrote:

[posted to rush.general]

	OK Dan, just tested with Maya 2013 + Scientific Linux 6.3
	and could replicate the error, and work around it.


	REPLICATION
	-----------
	Created /tmp/foo.py with the contents:

import os,sys
print >> sys.stderr, "Hello world."


	Opened a fresh install of Maya 2013, and in the Maya python editor ran:

import os
os.system("python /tmp/foo.py")

	..which gave the following error in the unix terminal
	that I invoked Maya from:

--- snip
Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
'import site' failed; use -v for traceback
Traceback (most recent call last):
 File "/tmp/foo.py", line 1, in <module>
   import os,sys
ImportError: No module named os
--- snip

	ANALYSIS
	--------

	I noticed PYTHONPATH and LD_LIBRARY_PATH both set in a way that I thought
	would break the OS version of python.

	SOLUTION
	--------
	So I modified the above command to unset those two variables
	as part of the command being run:

os.system("unset PYTHONPATH; unset LD_LIBRARY_PATH; python /tmp/foo.py")

	..and that worked fine.. printed 'Hello world.' in the terminal,
	and returned '0' as the exit code.

	With that working, I was able to include those 'unset' commands
	to run the rush submit_maya.py python script as well and submit
	a job successfully:

os.system("unset PYTHONPATH; unset LD_LIBRARY_PATH; python /eagle/net/rushscripts-103/python/submit_maya.py")

	HTH.

-- 
Greg Ercolano, erco@(email surpressed)
Seriss Corporation
Rush Render Queue, http://seriss.com/rush/

Tel: (Tel# suppressed)ext.23
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)


----------
Dan "Doc" Browne
System Administrator
Evil Eye Pictures

dbrowne@(email surpressed)
Office: (415) 777-0666 x105