It seems that Pydev (1.5.4) on Eclipse (3.5.1) with Python 2.6 isn't able to correctly cross-reference the package gobject. Putting import gobject works OK but any more than that (e.g. class X(gobject.GObject) causes Pydev to report "unresolved reference" errors.
What could be the problem?
Note that every other package I use doesn't trigger this error.
The issue is related to this limitation of PyDev:
I have a library installed and Pydev
does not find it
Well, problems have been reported on
Mac and Linux, and the main reason
seems to be symlinks. Pydev will only
find extensions that are 'really'
below the python install directory.
This happens because the 'less common
denominator', which in this case is
windows, does not have symlinks. A
workaround to this problem includes
manually adding the given folder
installation to the pythonpath or
changing the installation of the
package to be under the site-packages
folder.
To adjust for this limitation, find the absolute path to the library and update the libraries associated with the interpreter for Pydev.
Related
Error: The selected wizard could not be started.
Plug-in org.python.pydev was unable to load class org.python.pydev.ui.wizards.project.PythonProjectWizard.
An error occurred while automatically activating bundle org.python.pydev (547).
This error occurs as a result of installing the wrong version of PyDev for the version of Eclipse that you're using (found a hint on SO here).
For example, I (Edit: used to) use Eclipse Luna (Service Release 2, v4.4.2). I tend to lose my plugins / settings every time I update Eclipse on a Mac, and I'm too lazy to look into why, so I've avoided updating. Which is how I ran into the problem you describe here.
The version of PyDev available in the Eclipse Marketplace is, as of this writing, 6.5.something. You'd think Eclipse would be smart enough not to allow incompatible plugins to be installed with the Marketplace installer, but nope.
Look here for an idea of which version of PyDev you need to work with your version of Eclipse (check the "About" box within Eclipse), then follow the instructions here to download the appropriate .zip from SourceForge, extract it, and move the extracted files into the dropins directory, preserving the hierarchy that existing inside the archive.
For Eclipse Luna (4.4), I found that PyDev 5.2.0 seems to work fine (so far).
Note that the location of the dropins folder may vary by operating system. Once upon a time, I bookmarked this reference (for Luna) from the Eclipse help, and it may be useful somehow.
I am using Eclipse 4.2.1 with the pydev Plugin (version 2.7.1) for python development.
It seems that pydev has problems with precompiled python files (*.pyc files). I am using a package which is only provided with such precompiled files.
When importing a module, pydev shows "unresolved import" error. And also tool tips are not provided for such precompiled modules.
But the code can be executed without any errors.
Is there any way to "teach" pydev, how to deal with *.pyc files?
It seems like a bug. There is similar tread at http://sourceforge.net/projects/pydev/forums/forum/293649/topic/4651083:
I have installed eclipse installed along with enthought. I can import my standard python modules no problem, but as soon as try to import my enthought modules I get an import error. I cant find the folder/location as to where the enthought modules are, so I can add that folder directly to eclipse.
Can someone point me as to where enthought installs the modules so I can add it to eclipses python path?
EDIT:
I'm on Mac OS X 10.7.2
Using Python 2.7
First, you need to install pydev, the Python plugin for Eclipse.
Because only with that the PYTHONPATH becomes manageable.
Then you need to go to Settings->Pydev->Python Interpreter and pick the python interpreter you are using (and that uses the correct path to find all the other EPD modules).
So, if for example you are using the newest Enthought 7.2, then your Python interpreter for that would be in:
/Library/Frameworks/Python.framework/Versions/7.2/bin
In there you pick the python executable, and the Pydev plugin will then analyze all paths so that they will be known, even including automatic completions.
In continuing to research a solution for this question on ServerFault:
https://serverfault.com/questions/221203/mercurial-hook-fails-on-windows
I discovered an interesting and somewhat disturbing thing: I have seem three different versions of Python on my machine (four if you count the "official" version which doesn't appear to have a DLL with it....). Here's shot from my file search tool:
More Info:
I am running Windows 7 64-bit
Both the TortoiseHG and the Mercurial directories are on my path, with the Mercurial directory listed first.
I have Python 2.6 installed in c:\Python26
I have no entry for any type of PYTHON-based environmental variable. (Should I?)
I suspect that this is the source of the my problem from the question above, but I thought I'd ask here, as this is particular issue is a Python deal.
I tried to replace both DLLs with each other, but when I use the one that comes with Mercurial, then TortoiseHg stops working.
It seems to me that "there should only be one" Python on my machine. How do I achieve that?
For the problem that you mentioned earlier, the mercurial package got installed within python under mercurial home but you are executing scripts under C:\python26. So you need to install and execute your script under mercurial python
As seth mentioned earlier it is perfectly ok to multiple python homes in the same machine but you just to pay attention when installing python libraries to make sure that you are under the right home which means you set the path right before calling python.
Side note: The Python installation in "C:\Python26" installs its DLL to the Windows directory, in your case "C:\Windows\SysWOW64".
Answering your serverfault question: As you installed Mercurial as standalone version, you'll have to place any packages that are accessed by hooks into Mercurial's library folder (if it has one, could also be "library.zip").
I would recommend you to uninstall the Mercurial standalone version and instead install Mercurial with pip. This makes updates easier and you can use your normal "site-packages" directory for both normal Python libraries and hg hooks.
I would assume that tortoise/mercurial have just embedded their own versions of python to do whatever they need to do.
I wouldn't worry about it, the DLLs won't stomp on each other -- the PATH is the last placed that windows searches to find DLLs.
See: http://msdn.microsoft.com/en-us/library/7d83bc18(v=vs.80).aspx
Each DLL is for that application. There is only one in your search path so you don't need to worry about conflicts.
Is something not working that prompted you to worry about this??
Your assumption that there should only be one is wrong, each application has bundled a specific version with a fixed API, you can't just drop another in and hope it'll work.
The Python DLL naming structure only provides the major version and revision numbers. You are probably looking at the DLLs for versions 2.6.1, 2.6.4, 2.6.5, and 2.6.6.
All of this doesn't really matter as long as each application contains its own copy of the python26.dll. Windows will not explore the PATH environment variable if there is a local copy of the file.
I setup PyDev with this path for the python interpreter
/System/Library/Frameworks/Python.framework/Versions/2.5/Python
since the one under /usr/bin were alias and Eclipse won't select it. I can run my python script now but cannot run the shell as an external tool. The message I get is
variable references empty selection ${resource_loc}
Same if I use {container_loc}
Any thoughts ?
Sunit
I installed the Python.org version as well, this is a must.
I finally got PyDev working in Eclipse by pointing the interpreter to:
/Library/Frameworks/Python.framework/Versions/2.6/bin/python
manually. If you don't do it manually (by using the Autoconfig) it seems to not find the right version.
Common practice seems to be to install an up-to-date Python 2.5 from python.org and use that instead of the system installation. I saw that recommended here and there when I got started on Mac OS X.
It installs under /Library (as opposed to /System/Library) so the system Python is intact. Pydev has /Library/Frameworks/Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/Python as its configured Python interpreter and all is well.
Can't state for sure that your trouble is due only to using the system's Python installation; in any case this way I have no trouble. Also, this way when you fiddle with your development environment (install things in site-packages, upgrade Python), anything that uses the system Python is sure to be unaffected.
I know this is a ancient post... but, in case of some newbee like me to get the better answer.
I just using "Eclipse Marketplace" from the "Help" menu and search for keyword "python" or "PyDev" to get PyDev, and get it successfully installed.
AND, you should add PyDev to the top-right dock.
For the instance, my eclipse on my laptop's OSX is (Version: Indigo Service Release 2 Build id: 20120216-1857).
Have fun, folks! :)
I believe ${resource_loc} or ${container_loc} (without any argument) are based on the current selection in your workbench when you are launching your script.
So are you selecting the right resource when selecting that script through the "external tool" runner ?
At least, click on the project name before you run one of the external programs.
Note: it works with a selection in the Navigator or Package Explorers views (the latest might not be available in PyDev environment though)