Interpreter re-configuration from editor to run-time? Is this possible?

I've been playing with trying to get this working, but I haven't had much luck so thought I'd come and ask you all. First, let me describe my problem a bit more:

I am developing Python for Maya. Maya ships all of its libraries as pyc files and do not include the py files. For this reason, the auto complete does not work straight out of the box. To get around this Autodesk has included some py files that a third party has generated solely for the purpose of providing a way of getting auto-complete. The py files simply provide the classes and functions' definitions and do not have any of the actual code (just the bare minimum to make the auto-complete functional). Adding this directory to the interpreter setup in PyCharm makes the auto-complete work.

What sucks is that while auto-complete is now working, it makes it so that I cannot run code. I am coming from Eclipse and since it uses pypredef for auto-complete I did not have to add an extra directory to the python path. What is happening in PyCharm is that since I am having to add this extra directory, it is taking precedence over Maya's actual modules when I try to run the module.

Can anybody suggest a way I might be able to get it working so that the interpreter will have this extra path needed for auto-complete to work while in the editor and then not have it when actually running the code?
9 comments
Comment actions Permalink
PyCharm should be able to generate skeletons of binary *.pyc modules while scanning your interpreter's paths. Please file a bug report in our issue tracker and provide more details on your environment.
0
Comment actions Permalink
Thanks for your reply.

I actually think now that I mis-interpreted what was happening and why it was not working. After your response I went and took a look at Maya's site-packages and noticed that although most of the modules do only have a pyc file (just tested these ones and they DO work out of the box with auto-complete), the main one has both a py and pyc. The problem seems to actually be that the py and pyc files have nothing in them. The py file has absolutely nothing in it, and the pyc file only has one line. I guess the module in question is getting its functions from a dll or something and these files are just placeholders. Not exactly sure what is going on with this setup. Anyway, this is why the third-party py files I described above are needed.

Should I still create a ticket even though the circumstances have changed quite a bit?
0
Comment actions Permalink
What is the name of this main module of Maya you are referring to?

You can determine which file actually contains the code for this module (let's call this module foo) this way:

>>> import foo
>>> foo.__file__
prettyPrint();
If the file of the module is *.pyc then you can also check its contents:

>>> dir(foo)
prettyPrint();
This expression should evaluate to a (potentially large) list of defined names.

I guess that the file containing the module in question is in fact a non-empty *.pyc file and that the *.py file for the module is also visible using PYTHONPATH. If my guess is right then PyCharm founds *.py and doesn't inspect the *.pyc file. You can try to move the *.py file into a temporary directory and check whether this breaks your code.
0
Comment actions Permalink
The main module is the cmds module. It is actually a package with only __init__.py and __init__.pyc inside. These are the 0kb and 1kb files I was referring to.

__file__ for cmds returns /Applications/Autodesk/maya2013/Maya.app/Contents/Frameworks/Python.framework/Versions/Current/lib/python2.6/site-packages/maya/cmds/__init__.py, which is correct location (the 0kb file). I am on OSX. I use Windows at work and I checked yesterday and found the same files also in Maya's site-packages folder.

Interesting. When I move those empty files elsewhere and start up Maya I get this error:

// Warning: file: /Applications/Autodesk/maya2013/Maya.app/Contents/scripts/others/retargeter.mel line 27: Failed to run file: /Applications/Autodesk/maya2013/Maya.app/Contents/MacOS/plug-ins/retargeterNodes.py //
// Error: file: /Applications/Autodesk/maya2013/Maya.app/Contents/scripts/others/retargeter.mel line 27:  (retargeterNodes) //

I will take a close look at this file and post back later with what I find.
0
Comment actions Permalink
Haven't taken a look at that file yet (have to run to work), but I did do one more quick test.

After removing the __init__.py and __init__.pyc files from their location and getting that error, I saved just an empty file called __init__.py to that location and launched Maya again. I did not receive the error this time and the cmds module worked the same as usual. When there was no __init__.py file at all I was able to import cmds (without error, which seems a bit strange) but the functions would not do anything.
0
Comment actions Permalink
// Warning: file: /Applications/Autodesk/maya2013/Maya.app/Contents/scripts/others/retargeter.mel line 27: Failed to run file: /Applications/Autodesk/maya2013/Maya.app/Contents/MacOS/plug-ins/retargeterNodes.py //
// Error: file: /Applications/Autodesk/maya2013/Maya.app/Contents/scripts/others/retargeter.mel line 27:  (retargeterNodes) //

Took a look at that file. All it is is a file that gets run on Maya launch that is importing cmds. Since __init__.py doesn't exist this module errored on load and threw this error. Disregard any significance towards this. All that is important is that __init__.py is empty yet is required. Auto-complete does not work because the functions do not seem to exist within the py or pyc files.
0
Comment actions Permalink
Thanks for your comments. Please file a bug report at our issue tracker and link back to this thread. We'll investigate the issue later on along with other Maya-related issues.
0
Comment actions Permalink

It would seem these this guy has theories (which in the comments on the blog post are refuted) that are the closest I've seen as to how they populate their python "maya" package.  http://www.akeric.com/blog/?p=828

 

A fine workaround would be enabling adding custom stub paths, since I'm currently running into the same issue.  It seems like this bug is stagnated though...any progress?

0

Please sign in to leave a comment.