Ok, so if I create a brand new virtualenv, then hop into that environment, go into a python shell within that environment, and run 'import logging', for instance, it imports absolutely fine. I can then start up eclipse, create a new interpreter based on the /bin/python in my virtualenv and if I open up a python console within eclipse, based on this new interpreter, I can run 'import logging' again without any problems. I can create a project, with this new interpreter and create a sample file with nothing but
import logging
print asdf
I'll get an 'unresolved import' error with the line 'import logging'. This can be resolved by adding in the system lib/pythonX.X directory (in my case /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6) to the interpreter configuration, but I'd be under the impression that this is counter-intuitive for what you'd want to be doing with eclipse and virtualenv.
I know the stuff that's in that lib/pythonX.X directory are pretty much nothing but the base classes, but if they should always be included, should they not just be included anyway? Is this not against the way virtualenv setting up links to these very classes within it's own lib/pythonX.X directory? Is adding the base python lib/pythonX.X directory to the eclipse interpreter the correct way to do this, or is there problems with doing this?
Am I getting confused by the whole setup, or is it actually confusing and I'm right to ask the question? Thanks for anyone who can help.
I think it's just confusing... You really have to add the paths of the base interpreter when configuring the virtualenv interpreter in PyDev (i.e.: in the command line, when you start that interpreter and do an import sys;print(sys.path), the folders of the base interpreter will probably be there, so, they also need to be in PyDev).
Related
I am trying to start a new PyDev Project and first need to setup the interpreter. The auto-config does not find a "valid interpreter". And so I must manual config. Perhaps someone with experience in this procedure knows of the specific name for the Interpreter Executable I am looking for. Thanks!
To get the interpreter you need to use, start the python interactive console in a shell and then do:
import sys; print(sys.executable)
The path printed is the interpreter you should use.
As a note, PyDev 4.6.0 is pretty old already, so, my suggestion would be upgrading to the latest release as many things were improved in the meanwhile.
I've had many questions about Python for which a suggested answer is often "use virtualenv", but I have a (lovingly maintained and perfectly functioning) Python installation that I'm loath to disturb.
I want to be absolutely sure, so I'll ask twice: Does use of virtualenv in any way disturb my "real" Python installation? Using virtualenv does not in any way modify the files or paths in my "real" installation, right?
Virtualenv creates separated Python environment. Python interpreter is linked from one of system-installed that you choose creating virtualenv( --python commandline switch) and, optionally, wheater use or not system site-packages (--system-site-packages).
All packages that you install using virtualenv remains only on virtualenv directory site-packages folder and do not mess system packages.
I've installed pytables under windows 7 64 bit and it passes all the tests. Both python from command prompt and IDLE can successfully see the StringCol class, and even the python console in Eclipse can see it.
However, PyDev's autocomplete can't discover the class, and editor keeps displaying an error that says undefined variable: StringCol
Despite the error, the following code runs successfully in eclipse, using PyDev
from tables import *
if __name__ == '__main__':
a = StringCol(34)
print (a)
I've switched workspaces, created projects from scratch, deleted the pyc that contains the class. Nothing seems to help. How do I make pydev recognize the class which is obviously sitting where it is supposed to?
Have you configured the "forced builtins" in the interpreter. From the getting-started guide:
Additionally, you may add other libraries that you want to treat as
builtins, such as os, wxPython, OpenGL, etc. This is very important,
because PyDev works on the java side only with static information,
but some modules don't have much information when analyzed statically,
so, PyDev creates a shell to get information on those.
I still cannot get PyDev and eclipse on MacOS to reliably import modules.
import csv generates an "Unresolved import:" error within PyDev; however, when I open Terminal and run the script from the interpreter it works fine.
PyDev is using the interpreter found at /usr/bin/python, which is pointing to Python 2.7.
The relevant files (csv.pyc and csv.pyo) are in /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7, which is in PYTHONPATH.
Actually, for the standard library, PyDev needs the .py files (from your description you only have the .pyc/.pyo files) -- it should give you a big warning when you try to configure an interpreter where the .py files are not available.
So, the recommended solution would be using a python distribution from http://python.org (instead of the default which comes with Mac OS) or grab the standard library from elsewhere and copy it over to where you have the standard library in Mac OS.
See the "IMPORTANT for Mac users" note at: http://pydev.org/manual_101_interpreter.html
Everytime you add a new module, you need to reconfigure the interpreter in PyDEV. Whenever you do that, don't forget to check the new module you are adding to make sure it's being added to the PYTHON PATH.
Alternatively, you can configure each project by adding the new module to it. But that means you will have to configure this on a project basis. I would do it the other way.
My eclipse tries to compile/build Perl files in my Java project and fails. I installed Perl EPIC just for syntax colouring, how can I get it to ignore errors?
I tried going into Project->Properties->Builders, and uncheck Perl Epic, this didn't change anything.
I'm using Eclipse :Helios Service Release 1
Build id: 20100917-0705
On Windows XP
I have basically the same issue as this question,
How can I set up Eclipse to edit Perl without the runtime checking?
I've been looking into similar issue for quite some time too. Apparently the Epic Perl plugin goes wildly checking anything/folder/file it finds inside the project, so like mine where I have config files, data directories, it goes inside and tries to validate "perl stuff", which evidently is an annoyance: the error log view displays a lot of useless information.
Did you try to uncheck the "Perl Auto Builder" ?
I'm not parsing this sentence in the context of your question: "My eclipse tries to compile/build perl files in my java project and fails."
Are you saying that you are running perl as a java project, and getting the inevitable error message because it is not java? Just wondering why you don't want to have your perl program set up as a perl project possibly referenced by your java project, assuming that that is what you are trying to do.
Generally, when I set up a perl project, I edit its properties and set its includes to match the current directory or local module paths. Assuming that there are self-written modules I must call, and they are not located on this machine (e.g. I wouldn't have FOO::smb on a windows machine -- it makes no sense. When I am developing for linux, I will put all my functions in there for convenience's sake)
In that case, I create a FOO directory in the workspace, and create a dummy FOO::smb module with however many stub functions in it to get me going and let my syntax highlighting and error checkign do their proper jobs for me. If I write dummy subs to match the real modules well enough, I can debug my scripts somewhat before uploading them. I figure that I should be well enough aware of what they are supposed to do anyway.
I will go so far as to dummy out CPAN modules assuming that installing them on my development workstation makes no sense or is impossible. Highlighting and syntax checking are both invaluable tools, and finding a way to make both of them work saves my sanity.