To help shed some light on what can be a sort of confusing frustrating issue: the basic problem is that, by default, maya.cmds is completely empty!
You can see this if you open up the actual text module file - if you're in maya, do: import maya.cmds; print maya.cmds.__file__ ...then open up that file in your favorite text editor. It's a whole bunch of white. All the maya commands that we know and love are actually generated and added to the maya.cmds module dynamically, once maya starts up. Ie, you can try this: (start mayapy) >>> import maya.cmds >>> print hasattr(maya.cmds, 'ls') False >>> import maya.standalone >>> maya.standalone.initialize() (maya will start up, and print stuff here) >>> print hasattr(maya.cmds, 'ls') True What this means for eclipse is that, if you point the python path to the true location of the maya module, it will successfully import the maya.cmds module, then scan it, and find there's nothing there. So when you then try to use maya.cmds.ls, it complains, saying there's no such function. In order to get it to successfully find all the maya.cmds stuff, you would actually have to get eclipse to run "import maya.standalone; maya.standalone.initialize()" before it scans any modules.... which you CAN get it to do, but it then means you're starting up an entire maya running session as a subprocess of eclipse, which would slow down startup immensely, and take up a whole bunch of memory. So, to help with this, pymel has some tools to scan all of maya.* (and pymel.* - since all the pymel stuff is autogenerated from the maya.cmds stuff, if that doesn't exist, neither can the pymel commands), and generate stub files. These files contain nothing but copies of the signatures of all the functions, classes, etc, but with empty bodies. Try opening up some of the stubs in %APPDATA%/Autodesk/Maya2013/devkit/other/pymel/extras/completion/py to see what I mean. The net result is that if you put these stub files onto eclipse's python path instead of the "real deal", eclipse will be able to happily find all the maya.cmds (and pymel.core.*) stuff, and autocomplete, etc. The only real downside of is that if you use the "F3" key a lot (like I do) to jump to the definition of things, it will open up the stub file. In the case of maya.cmds, this is actually better, since there is no "real" python source for the maya.cmds.* stuff - with the stub, you at least get to see the function signature! For pymel, though, it's less helpful, since for many pymel commands/classes/etc there IS "real" python source that you could look at. For this reason, if I'm doing a pymel work, I will often use an interpreter which points at the real pymel source instead of the stubs... basically, you have to choose between being able to browse to "real" pymel source, and not having a bunch of things like pymel.core.lsflagged incorrectly as errors. - Paul On Fri, Sep 21, 2012 at 12:13 AM, PixelMuncher <[email protected]> wrote: > You are da Man Justin! > C:\Program Files\Autodesk\Maya2013\devkit\other\pymel\extras\completion > \py > Not only did it fix all the import statements, but I now have code > completion for Maya commands, which never worked before. > There are some pretty complex instructions out there for getting > Eclipse/PyDev/Maya working, but all that appears to be needed is the > correct addition to PYTHONPATH. No forced built-ins, no predefined. > > Looking at __init__.py in the 'cmds' dir, I see an empty def for each > command. I assume that this is what is referred to as 'stubs'? > > Maybe I'm just a weenie who needs his list of defs to be visible all > the time, but I prefer this to Sublime > > Thanks a ton as always. > > -- > 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
