So it turned out to be the Qt dll's that did not load. I swear that I installed the same PyQt version that Maya uses, but I guess not.
Another interesting thing once I got that in place was that I kept getting a PyQt module not found error. PyQt is inserted in the Maya.env for us, and when I print the environment in Maya, that inserts it into the PYTHONPATH. When I run the subprocess and do from pymel.core import *, I assumed that the env should be accounted for when initiating pymel from stanalone? Somehow it is not picked up. As soon as I add our custom PyQt4 location to sys.path, everything works. I ended up modifying our injectPaths method to add PyQt4 to sys.path as well, which is a part of our whole start up flow with Maya ( http://christianakesson.com/2012/218#mayaMenuBoot) and now I am in happy land... Thanks all for your help on this. /Christian On Thu, Jul 19, 2012 at 11:26 AM, Paul Molodowitch <[email protected]>wrote: > Hmm... well, if it really is as simple as tinkering with the PATH env var, > then it should be pretty easy to do from python, since you're calling > mayapy as a subprocess. One of the kwargs to subprocess.Popen provides the > ability to pass in a dict which is used for the environment for the newly > spawned process - just copy the os.environ, and modify the PATH in the > modified copy. (Or, you could just modify os.environ['PATH'] directly > before calling subprocess, if you don't mind "globally" altering your > path...) > > - Paul > > > On Wed, Jul 18, 2012 at 12:25 PM, Christian Akesson < > [email protected]> wrote: > >> That was it, again, thanks Paul. Tested with the nuke (copy every dll >> from maya to the compiled program's directory). >> http://msdn.microsoft.com/en-us/library/7d83bc18(v=vs.71).aspx - dll >> search order in windows. >> >> Seems to me that the simplest method is the last bullet - The >> directories listed in the PATH environment variable. >> >> The PATH environment variable is not the same as doing >> sys.path.append(path)? >> The C:\Program Files\Autodesk\Maya2012\bin is already appended to >> sys.path.... >> >> I will get to this later this afternoon, but if anyone have experience >> with DLL path resolution and particularly the windows PATH environment >> variable, I would love to hear about it. Is there a way to set that >> temporarily for the process through Python? >> >> Thanks >> >> /Christian >> >> >> >> On Wed, Jul 18, 2012 at 11:45 AM, Christian Akesson < >> [email protected]> wrote: >> >>> Tried that out right quick: >>> File >>> "W:/Tools/SOEglobal/python/SOEmayaTools/soe_mayaBatch/commandNodes/export.py", >>> line 6, in <module> >>> from maya.OpenMaya import MGlobal >>> File >>> "c:\buildforge\Maya_2012_Win64_Build\build\wrk\optim\runTime\Python\Lib\site-packages\maya\OpenMaya.py", >>> line 7, in <module> >>> ImportError: DLL load failed: The specified procedure could not be found. >>> >>> I will look into dynamic-library-path-resolution on windows. Thanks for >>> your reply. >>> >>> /Christian >>> >>> >>> >>> On Wed, Jul 18, 2012 at 11:34 AM, Paul Molodowitch >>> <[email protected]>wrote: >>> >>>> It looks like some sort of dll linking error - for whatever reason, >>>> when run inside of your app, it looks like it can't find the standard maya >>>> dlls. >>>> >>>> Try this - instead of doing "from pymel.core import *", just try "from >>>> maya.OpenMaya import MGlobal". Does that work? If not, you need to look >>>> into the specific details of dynamic-library-path-resolution on windows, >>>> and figure out how to get it to find the maya dlls. I don't really know >>>> much about those details on windows, but I know that on linux, executables >>>> can add paths onto the list of paths to search for dynamic libs, and those >>>> paths may be inherited (or even override) the paths for other libraries it >>>> loads - perhaps something similar exists on windows? >>>> >>>> - Paul >>>> >>>> On Wed, Jul 18, 2012 at 11:06 AM, Christian Akesson < >>>> [email protected]> wrote: >>>> >>>>> I should also add that the way the batch start module (CA_batcher.py >>>>> in the UI) is called from the compiled application is the below: >>>>> >>>>> def mayaBatch(self): >>>>> """ Kick off the batch sessions""" >>>>> # Verify call >>>>> if self.verifyMayaBatchInputs(): >>>>> self.updateXMLForMayaBatch() >>>>> commandPath = soe_path.Path(self.mayaBatchStartUp) >>>>> sys.path.append(os.path.split(commandPath)[0]) >>>>> fp, pathname, description = imp.find_module(commandPath.namebase) >>>>> imp.load_module(commandPath.namebase, fp, pathname, description) >>>>> >>>>> /Christian >>>>> >>>>> >>>>> >>>>> On Wed, Jul 18, 2012 at 11:03 AM, Christian Akesson < >>>>> [email protected]> wrote: >>>>> >>>>>> Hi Justin, thanks for your reply. >>>>>> >>>>>> Yes, I am packing into a standalone app, using GUI2EXE and py2exe. >>>>>> The setup script is attached. The only thing I do special in the setup is >>>>>> the below portion, which pretty much adds the environment I have in >>>>>> Eclipse >>>>>> to the system paths (surely the formatting will get shredded): >>>>>> >>>>>> import xml.etree.ElementTree as ET >>>>>> import getpass >>>>>> import sys >>>>>> from os import path >>>>>> remoteTBLoc = '//Sdlux3/Projects2/StudioArt/SOEglobal' >>>>>> if path.exists("%s/data/%s/SOEG.xml" % (remoteTBLoc, >>>>>> getpass.getuser())): >>>>>> userXML = ET.parse('%s/data/%s/SOEG.xml' % (remoteTBLoc, >>>>>> getpass.getuser())) >>>>>> userXMLCore = userXML.getiterator('Core')[0] >>>>>> SOEGUprojectToolPath = userXMLCore.get('SOEprojectToolPath') >>>>>> sys.path.append('%s/python/SOEcommon' % SOEGUprojectToolPath) >>>>>> from core import soeg >>>>>> soeg.SOEG().loadSysPaths(artBuild=0) >>>>>> else: >>>>>> print 'ERROR - SOEG needs to be installed' >>>>>> >>>>>> >>>>>> I am confused about one thing. If you look at the ui image attached >>>>>> in the original post, the actions listed are python modules, that lives >>>>>> in >>>>>> the Actions Directory package (see ui image). This is dynamically >>>>>> displayed, and none of them are included in the compiled program. When I >>>>>> run, for simplicity's sake a single action, the batch starter (see ui) is >>>>>> called. >>>>>> >>>>>> In this case, the CA_batcher.py, will for each file that is listed in >>>>>> the Files & Folder tab kick off a subprocess: >>>>>> for eachFile in treatFiles: >>>>>> mayaProcess = subprocess.Popen([mayaPyPath, action, eachFile]) >>>>>> mayaProcess.wait() >>>>>> >>>>>> So a subprocess is created calling mayapy.exe with the action >>>>>> (export) module being called. I was under the impression that when you >>>>>> call >>>>>> from pymel.core import * in a mayapy.exe session that your environment >>>>>> was >>>>>> being initialized and that seems to happen when I run this program the >>>>>> exact same way inside Eclipse. >>>>>> >>>>>> When that failed, I tried to initialize the environment manually in >>>>>> the action (export) module, but nothing seems to get the from pymel.core >>>>>> import * to go. >>>>>> >>>>>> i.e nothing pymel or Maya is being used inside the compiled program >>>>>> itself. The only time that is being used is when the subprocess is >>>>>> created >>>>>> to the external action. >>>>>> >>>>>> Could there be some dependency somewhere within the program itself >>>>>> that causes the subprocess to look inside the compiled exe for pymel? >>>>>> I've >>>>>> combed for that, but not been able to find anything. >>>>>> >>>>>> Thanks for having a look, I'm hoping that I am missing something... >>>>>> >>>>>> /Christian Akesson >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Jul 18, 2012 at 8:23 AM, Justin Israel < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> What are you "compiling" with? Do you mean that you are packaging it >>>>>>> into a standalone app with something like py2exe or pyinstaller? If so, >>>>>>> what does your setup file look like? Its most likely related to missing >>>>>>> dependencies. When you package libraries that have some substantial .dll >>>>>>> deps it can be a bit of an extra process to specify them so they are >>>>>>> included. >>>>>>> Pygame apparently has this same situation, where py2exe will list a >>>>>>> special "recipe" section for it on the wiki. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Jul 17, 2012, at 11:19 PM, Christian Akesson < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>> I've written a standalone compiled Python & PyQt program. It is a >>>>>>> framework for all things batching, where separate modules can be written >>>>>>> outside of the main program and then gets read by the main program. >>>>>>> >>>>>>> One of the things I set it up to do is doing batch jobs with Maya. >>>>>>> When developing it in Eclipse, I ran a Python 2.6.4 interpreter (x64) - >>>>>>> same as Maya 2012 x64 is running on from what I have gathered. >>>>>>> Everything >>>>>>> works like a charm inside Eclipse. I compile the program and the moment >>>>>>> I >>>>>>> run the batch code. which uses mayapy.exe ( >>>>>>> http://download.autodesk.com/global/docs/maya2012/en_us/PyMel/standalone.html) >>>>>>> in a subprocess, I get this error spew: >>>>>>> >>>>>>> Traceback (most recent call last): >>>>>>> File >>>>>>> "W:/Tools/SOEglobal/python/SOEmayaTools/soe_mayaBatch/commandNodes/export.py", >>>>>>> line 6, in <module> >>>>>>> from pymel.core import * #@UnusedWildImport >>>>>>> File "C:\Program >>>>>>> Files\Autodesk\Maya2012\Python\lib\site-packages\pymel\core\__init__.py", >>>>>>> line 6, in <module> >>>>>>> import pymel.versions as _versions >>>>>>> File "C:\Program >>>>>>> Files\Autodesk\Maya2012\Python\lib\site-packages\pymel\versions.py", >>>>>>> line >>>>>>> 12, in <module> >>>>>>> from maya.OpenMaya import MGlobal as _MGlobal >>>>>>> File >>>>>>> "c:\buildforge\Maya_2012_Win64_Build\build\wrk\optim\runTime\Python\Lib\site-packages\maya\OpenMaya.py", >>>>>>> line 7, in <module> >>>>>>> ImportError: DLL load failed: The specified procedure could not be >>>>>>> found. >>>>>>> >>>>>>> If I remove the from pymel.core import * from that module >>>>>>> (export.py), it will go into our library and start running the batch. >>>>>>> The >>>>>>> problem is that we have deeply integrated pymel, so whenever it hits >>>>>>> that >>>>>>> call in our other modules, I get that same error. >>>>>>> >>>>>>> I've sys.path.append-ed our entire environment manually to make sure >>>>>>> it's not an environment thing. I've printed out which python version, >>>>>>> bit >>>>>>> depth that is being run in both the main program as well as in the >>>>>>> mayapy >>>>>>> subprocess and they are the same. >>>>>>> >>>>>>> Does anyone have any clue to what could be going on here? >>>>>>> Running Maya 2012 service pack 2 and PyMel 1.0.3 >>>>>>> >>>>>>> The fact that it runs like a charm when running inside of eclipse >>>>>>> has got to be a clue and is really frustrating at the same time :-). >>>>>>> >>>>>>> <image.png> >>>>>>> >>>>>>> >>>>>>> >>>>>>> /Christian >>>>>>> >>>>>>> -- >>>>>>> view archives: http://groups.google.com/group/python_inside_maya >>>>>>> change your subscription settings: >>>>>>> http://groups.google.com/group/python_inside_maya/subscribe >>>>>>> >>>>>>> -- >>>>>>> view archives: http://groups.google.com/group/python_inside_maya >>>>>>> change your subscription settings: >>>>>>> http://groups.google.com/group/python_inside_maya/subscribe >>>>>>> >>>>>> >>>>>> >>>>> -- >>>>> view archives: http://groups.google.com/group/python_inside_maya >>>>> change your subscription settings: >>>>> http://groups.google.com/group/python_inside_maya/subscribe >>>>> >>>> >>>> -- >>>> view archives: http://groups.google.com/group/python_inside_maya >>>> change your subscription settings: >>>> http://groups.google.com/group/python_inside_maya/subscribe >>>> >>> >>> >> -- >> view archives: http://groups.google.com/group/python_inside_maya >> change your subscription settings: >> http://groups.google.com/group/python_inside_maya/subscribe >> > > -- > view archives: http://groups.google.com/group/python_inside_maya > change your subscription settings: > http://groups.google.com/group/python_inside_maya/subscribe > -- view archives: http://groups.google.com/group/python_inside_maya change your subscription settings: http://groups.google.com/group/python_inside_maya/subscribe
