We Keep Coding

Can't import library in Python - Ubuntu 12.04

I have been trying for 3 days now with now luck, I really am desperate.
I have installed NumPy, along with matplotlib. I am trying to include matplotlib into my applications, but it does not work. I am using Eclipse with the PyDev plug-in, but whenever I try to import it, I get an error, even though I have added it to the libraries that it needs to import every time.
I am a beginner with Linux and I don't really know how to do stuff of the top of my head. I would like to know if this is related to PYTHONPATH and if so, how can I change it?
Also, when running whereis matplotlib, I get matplotlib: usr/share/matplotlib.
EDIT
Even though I did not manage to solve the problem, nor am I interested any more, I consider this question closed. I have decided to use the free version of PyCharm, as suggested by #FooBarUser.

On my Ubuntu 12.04, modules like these are installed in /usr/local/lib/python2.7/dist-packages. Adding that to PYTHONPATH may help resolve the issue.In my ~/.bashrc I have
export PYTHONPATH=...
export PYTHONPATH=/usr/local/lib/python2.7/dist-packages:$PYTHONPATH
export PYTHONPATH=
Edit: if you also have Python 3 installed on your system, numpy might also be in
/usr/lib/pyshared/python2.7/numpy
If the latest version of numpy was built to be backwards compatible with both 2.7 and 3.*, the installer might put it in that directory which is meant for packages which can be shared across multiple python version numbers.

Proper Unix (.profile, .bash_profile) changes for Python usage

I new to Python and to programming in general. I'm a novice, and do not work in programming, just trying to teach myself how to program as a hobby. Prior to Python, I worked with Ruby for a bit and I learned that one of the biggest challenges was actually properly setting up my computer.
Background: I'm on a Macbook with OSX 10.7.
With Ruby, you have to (or rather, you should), edit your ./profile and add PATH info. When you install and use RVM, there are additional items you need to add to your bash_profile.
Do you have to make similar changes with Python? What are the best practices as I'm installing/getting started to ensure I can install modules and packages correctly?

python works out of the box on OS X (as does ruby, for that matter). The only changes I would recommend for a beginner are:
1) Python likes to be reassured that the terminal can handle UTF-8 before it will print Unicode strings. Add export LANG=en_US.UTF-8 to .profile. (It may be that the .UTF-8 part is already present by default on Lion - I haven't checked since Snow Leopard.) Of course, this is something that will help you in debugging, but you shouldn't rely on it being set this way on other machines.
2) Install pip by doing easy_install pip (add sudo if necessary). After that, install Python packages using pip install; this way, you can easily remove them using pip uninstall.

Take a loot at Python on the Macintosh page first. Like it says, Python comes pre-installed on Mac OS X. It means that you don't have to do anything special in order to use it.
To get started, you can run a Terminal.app, type python and that will get you Python interactive shell up and running.
However, Python on OS X might be of a slightly older version. For example, OS X 10.7.3 comes with Python 2.7.1, whereas latest release version of the Python is 3.2.3. If you want to use other versions, then you will have to install them. Then it all depends on what, where and how you install. If you want to have multiple versions alongside, you may need to set some environment variables like PATH to have binaries you installed found by the bash etc. You can do it through bash ~/.profile if needed.
But until you get to that point - don't worry about it use a version shipped with OS X. Once you want a newer one - download and install it. Then, if it doesn't work out of the box or you have any other problems or concerns, feel free to ask a more specific question.

Using PIL on multiple systems

looking for some advice and best practice guidance with the following situation. I have a python application that is run from source and has all dependencies included. When using PIL some issues arise. Different python versions need different PIL sources and 64 bit and 32 bit need different version.
We have decided we want to support:
Python 2.4 64 bit
Python 2.4 32 bit
Python 2.7 64 bit
Python 2.7 32 bit
I will have to locate the necessary source packages and include them all. The question is what is the best way to import them? Do I check python version and OS version and import different PIL versions based on that (can you if, else import stuff?) or can I import once for all?
Hope that all makes sense. Thanks

I'm going to take the opposite direction of #alan's answer and not recommend you even distribute your 4 hard-coded environments like that.
If you are distributing source code directly, then you shouldn't be including prebuilt dependencies at all. Create some kind of setup.py to have the dependencies downloaded and installed. Or consider packaging your app into a self-contained executable
Your package could contain the setup files for PIL locally so a download wouldn't be needed, but they should get built by the actual end-user to match their architecture. There is no point in trying to make your application figure all of this out and point to one of many precompiled packages.
You can also take a look at py2exe, py2app, and pyinstaller if you want to go the route of creating self-executable packages for different systems that contain their entire environment.

Have you heard of virtualenv? http://pypi.python.org/pypi/virtualenv
From your stated requirements, I believe it will do what you need. It was created specifically to solve the problem of installing and maintaining different environments for different versions of Python and different packages installed for each version.
Take a look and see if it does what you need, though I believe you would need two different boxes (or VMs) to separate the 32- and 64-bit environments.
At any rate, once you have your four environments set up, you would just activate an enviroment and the import PIL statement in Python code running in that environment would get the proper library.

How to maintain long-lived python projects w.r.t. dependencies and python versions?

short version: how can I get rid of the multiple-versions-of-python nightmare ?
long version: over the years, I've used several versions of python, and what is worse, several extensions to python (e.g. pygame, pylab, wxPython...). Each time it was on a different setup, with different OSes, sometimes different architectures (like my old PowerPC mac).
Nowadays I'm using a mac (OSX 10.6 on x86-64) and it's a dependency nightmare each time I want to revive script older than a few months. Python itself already comes in three different flavours in /usr/bin (2.5, 2.6, 3.1), but I had to install 2.4 from macports for pygame, something else (cannot remember what) forced me to install all three others from macports as well, so at the end of the day I'm the happy owner of seven (!) instances of python on my system.
But that's not the problem, the problem is, none of them has the right (i.e. same set of) libraries installed, some of them are 32bits, some 64bits, and now I'm pretty much lost.
For example right now I'm trying to run a three-year-old script (not written by me) which used to use matplotlib/numpy to draw a real-time plot within a rectangle of a wxwidgets window. But I'm failing miserably: py26-wxpython from macports won't install, stock python has wxwidgets included but also has some conflict between 32 bits and 64 bits, and it doesn't have numpy... what a mess !
Obviously, I'm doing things the wrong way. How do you usally cope with all that chaos ?

I solve this using virtualenv. I sympathise with wanting to avoid further layers of nightmare abstraction, but virtualenv is actually amazingly clean and simple to use. You literally do this (command line, Linux):
virtualenv my_env
This creates a new python binary and library location, and symlinks to your existing system libraries by default. Then, to switch paths to use the new environment, you do this:
source my_env/bin/activate
That's it. Now if you install modules (e.g. with easy_install), they get installed to the lib directory of the my_env directory. They don't interfere with existing libraries, you don't get weird conflicts, stuff doesn't stop working in your old environment. They're completely isolated.
To exit the environment, just do
deactivate
If you decide you made a mistake with an installation, or you don't want that environment anymore, just delete the directory:
rm -rf my_env
And you're done. It's really that simple.
virtualenv is great. ;)

Some tips:
on Mac OS X, use only the python installation in /Library/Frameworks/Python.framework.
whenever you use numpy/scipy/matplotlib, install the enthought python distribution
use virtualenv and virtualenvwrapper to keep those "system" installations pristine; ideally use one virtual environment per project, so each project's dependencies are fulfilled. And, yes, that means potentially a lot of code will be replicated in the various virtual envs.
That seems like a bigger mess indeed, but at least things work that way. Basically, if one of the projects works in a virtualenv, it will keep working no matter what upgrades you perform, since you never change the "system" installs.

Take a look at virtualenv.

What I usually do is trying to (progressively) keep up with the Python versions as they come along (and once all of the external dependencies have correct versions available).
Most of the time the Python code itself can be transferred as-is with only minor needed modifications.
My biggest Python project # work (15.000+ LOC) is now on Python 2.6 a few months (upgrading everything from Python 2.5 did take most of a day due to installing / checking 10+ dependencies...)
In general I think this is the best strategy with most of the interdependent components in the free software stack (think the dependencies in the linux software repositories): keep your versions (semi)-current (or at least: progressing at the same pace).

install the python versions you need, better if from sources
when you write a script, include the full python version into it (such as #!/usr/local/bin/python2.6)
I can't see what could go wrong.
If something does, it's probably macports fault anyway, not yours (one of the reasons I don't use macports anymore).
I know I'm probably missing something and this will get downvoted, but please leave at least a little comment in that case, thanks :)

I use the MacPorts version for everything, but as you note a lot of the default versions are bizarrely old. For example vim omnicomplete in Snow Leopard has python25 as a dependency. A lot of python related ports have old dependencies but you can usually flag the newer version at build time, for example port install vim +python26 instead of port install vim +python. Do a dry run before installing anything to see if you are pulling, for example, the whole of python24 when it isn't necessary. Check portfiles often because the naming convention as Darwin ports was getting off the ground left something to be desired. In practice I just leave everything in the default /opt... folders of MacPorts, including a copy of the entire framework with duplicates of PyObjC, etc., and just stick with one version at a time, retaining the option to return to the system default if things break unexpectedly. Which is all perhaps a bit too much work to avoid using virtualenv, which I've been meaning to get around to using.

I've had good luck using Buildout. You set up a list of which eggs and which versions you want. Buildout then downloads and installs private versions of each for you. It makes a private "python" binary with all the eggs already installed. A local "nosetests" makes things easy to debug. You can extend the build with your own functions.
On the down side, Buildout can be quite mysterious. Do "buildout -vvvv" for a while to see exactly what it's doing and why.
http://www.buildout.org/docs/tutorial.html

At least under Linux, multiple pythons can co-exist fairly happily. I use Python 2.6 on a CentOS system that needs Python 2.4 to be the default for various system things. I simply compiled and installed python 2.6 into a separate directory tree (and added the appropriate bin directory to my path) which was fairly painless. It's then invoked by typing "python2.6".
Once you have separate pythons up and running, installing libraries for a specific version is straightforward. If you invoke the setup.py script with the python you want, it will be installed in directories appropriate to that python, and scripts will be installed in the same directory as the python executable itself and will automagically use the correct python when invoked.
I also try to avoid using too many libraries. When I only need one or two functions from a library (eg scipy), I'll often see if I can just copy them to my own project.

Curious about python installation paths, especially on OSX

First: I'm running Macports. No problems with that, except:
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/bin
which is the value of sys.exec_prefix, for my macports python even though:
/opt/local/lib/python2.6/site-packages/
seems to be quite a logical place to put things, /opt/local being the macports --prefix, as it were. Why does easy_install put things in this odd Frameworks/Python.framework thing?
More importantly, can i use the methods here, to ensure that all my systemwide python, particularly the scripts which I really want in /opt/local/bin, things I use all over the place like (i|b)python for example are accessible?

So first I'd make the observation that the directory
/Library/Frameworks/Python.framework/Versions/2.6/...
is where you can find the OS X provided version of Python so I'd guess that what the MacPorts developers want to do is replicate the OS X Python directory structure but keep it as far away from the OS X version of Python as possible. Also I think replicating the structure allows you to install third-party extensions outside of the MacPorts modules. I've done that before so I know it's possible, its just you still need to make sure:
When installing the modules, the version that the installer encounters when doing a PATH search is the Python installation you want to install it to (ie. a module meant for MacPorts Python doesn't end up in OS X Python). The page you cited earlier spells out the procedure an installer goes through when trying to find a Python installation to install to so you have some hints there about what to look into if you have problems installing third party modules.
Once you have installed your modules you'll have to keep track of them yourself because MacPorts won't do that for you. On the bright side everything should be in the site-extensions folder of the Python installation, I think.
This question from the MacPorts FAQ kind of lays the groundwork for their philosophy of directory organization I think. Also this question too.