Package predicament or distribution dilemma, part 2

[UPDATE 2013-05-01]

Another post so hopelessly outdated, that it's almost better off just deleting. On the flip side it's instructive to relive, however painful  my learning process. So I addressed the issue of building Numpy from source using Pip in both the system (local) environment and in a virtualenv (always recommended) in an update to the next and final installment of this 3-part post: Package Predicament Part 3: Python, the final installment, and in there I also link to the solution: Building numpy, scipy, matplotlib and PIL in virtualev on both windows and linux. In a nutshell my intuition in (a) below was correct. In particular Numpy requires both C and Fortran compilers, and the source for its dependencies, or at least their headers, specifically BLAS and LAPACK. However the issue of building Numpy was peripheral to the real question in this series of where and when to deviate from the Ubuntu package repository. My answers, now, would be as follows:

• If the package is not in the repository, consider a ppa (personal package archive) such as this one for Sublime Text 2 by W8, or if possible drop a prebuilt binary installed ~/opt and add a symlink to it from ~/bin as I described here in this post: Install Add On Software and Create GTK+ Desktop File.
• If the package is in the repository, but you want a different version then if the package is a python or ruby package consider using a virtualenv or rvm. This protects your system environment from differently named or different versions and possibly conflicting dependencies. For example chardet is a Requests dependency, but in ubuntu it's named something different than it is on Pypi, causing it to be installed twice and confuse everyone. Placing your off-repo version of requests in a virtualenv protects your system and avoids the conflict. Ubuntu does have a place to put your system python files, but I would almost never use it. For packages that are add-ons, I would do the same thing I did for eclipse which I described in this post: Eclipse in ubuntu.

Stick this these rules and you will always be happy! I promise!

So here's the flip. Just for kicks I tried to update numpy, stupid because (a) it includes a lot of binaries that need to be compiled, not just py code and (b) it's so mature what could possibly be in 1.6.1 that's not in 1.5.9?

So pip scream loudly on and on about this not being where it looked and this not compiling and finally, installation failed. Luckily for me it underwent all this trauma in a temp file called ~/build so my system was never altered.

Made me think though... maybe I should try some of these "experiments" on a vm so my real system won't get trashed.