Develop Reference

Using my Installation of Boost Python for PyVlFeat

I am trying to install PyVlFeat and the installation is failing with exactly this issue mentioned here.
pyvlfeat error during installation: /usr/bin/ld: cannot find -lboost_python-mt-py26
As per the answer mentioned there, I need to change the reference of "-lboost_python-mt-py26" to the correct version of Boost Python I have on my system.
I am on ubuntu 14.04 and I tried to detect the version of my boost python by using this command "ls /usr/lib/libboost_python*"
I don't seem to have any libraries with a similar name there. However, I have installed Boost Python using this command "sudo apt-get install libboost-all-dev" as mentioned here.
https://stackoverflow.com/questions/25891667/boost-undefined-reference-ubuntu-14-04-boost-1-54
Since Boost Python is already there, how should I use it correctly to compile PyVlFeat.

The -mt suffix had been removed from Boost Libraries. The installed Boost libraries are multi-threading safe.
Changing the reference to "-lboost_python-py27" (Removing -mt suffix and using proper version of python will solve the problem.

Installing QuTIP 2.2.0 with existing Python distribution on Windows

Has anyone managed to install QuTIP 2.2.0 with an existing Python 2.7.5 distribution (on Win7)? The instruction manual suggests that I need to install Python(x,y) first, but the instructions are pretty vague. I'm still a Python newbie.

Understanding installation instructions
The installation instructions are pretty clear, but I remember the times, I got lost in those short lines assuming I know something obvious.
I will try translating it
install Python(X,Y) - do it. Follow the link, download the exe file and run it.
Do not forget to set the options, following defaults will fail, Cython option must be included.
edit the distutils.cfg file as instructed
download tar.gz archive for QuTIP from PyPi, unpack it in some directory, cd into it to be in the directory, where you see setup.py, and run $ python setup.py install
The distutils.cfg refers to mingw32, this is needed for compilation. If it is not installed with Python(X,Y), you would have to install it separately. Be careful and install proper version, even on 64 bit systems use 32 bit one (this I assume from proposed name of compiler in config).
Good luck. I am not on Windows for about 2 years, so I cannot confirm, it works, but I hope, it will move you on.

I also had a lot of problems installing it correctly.
Here is my working solution.
As the installation instructions suggest:
Install PythonXY (I am using 2.7.6.1) (including Cython package) (Edit: The newer versions of PythonXY do not include a compiler. Try installing from here instead: https://code.google.com/p/pythonxy/wiki/AdditionalPlugins)
Edit C:\Python27\Lib\distutils\distutils.cfg to include:
[build]
compiler = mingw32
[build_ext]
compiler = mingw32
Add C:/MinGW32-xy/bin to your PATH. It has to be before other paths with e.g. gcc in them. You can do this:
set PATH=C:/MinGW32-xy/bin;%PATH%
for a temporary add (in that console) or use the answer here.
For a permanent change go properties of your Computer. Go to advanced system settings --> Environment Variables. Change the System Variable to have the MinGW path as the first entry. It doesn't work if it is last or in the user path!
Run a Python interpreter:
import qutip; qutip.testing
qutip.testing.run()
If it doesn't crash on the 7th test you probably have a working copy of qutip.
I get 320 test in 2194.236s and SKIP=7, errors=5.
Details of which tests failed for my can be seen here.

I would use Anaconda 2.7 with the added mingw and libpython libraries and then edit the distutils.cfg as stated. The skipped tests mentioned are fortran tests that you cannot run on windows, while the errors are time dependent tests that generate cython code at run time. If you follow the above suggestions then those tests will pass.

I've tried to install qutip for several hours, unsuccessfully. Fortunately, kind people from University of California have a solution:
wheels for lots of packages for python computing
This resource is not official, 'as is', but works better!
Type 'pip install package.whl' to download and build.

Cannot Install py2cairo on Mac OSX

I am trying to install py2cairo on a framework build (Mac OSX Lion) of python 2.7.3 using brew. I have been unsuccessful this far.
First, I tried a simple
brew install py2cairo
This seems to work only on a non-framework build of python. When I do this on my framework build python faults as soon as I import cairo with an incompatible binary error.
Second, I have tried to build it myself by grabbing it from github and issuing:
python waf configure
This fails with:
Checking for library python2.7 : not found
Checking for library python2.7 : not found
Checking for library python2.7 : not found
Checking for library python27 : not found
Checking for program python2.7-config : /usr/local/Cellar/python/2.7.3/bin/python2.7- config
Checking for header Python.h : Could not find the python development headers
The configuration failed
(complete log in /Users/tobin/tmp/py2cairo/build_directory/config.log)
I have tried everything at: How to install PyCairo 1.10 on Mac OSX with default python but none of this has helped.
It appears to me that this may be failing to find python2.7 library and header file since it is a framework build. Is that possible? I was looking at the brew formula and it appears that framework builds do not get --enable-share set at build time. I'm not sure if that is relevant here - but maybe one possibility.
Anyone other insights would be great. Thanks in advance.
UPDATE:
I discovered that the inability to build py2cairo had to do with the use of the "-march=native" flag by gcc. gcc (4.2.1) on Mac OSX has issues with this. I then reinstalled gcc as well as python. Afterwards when building py2cairo with waf - it was getting "-march=core2" and everything built.
Unfortunately, not all is good yet. I get the same error when I import cairo from my build that I got from the brew version (as mentioned above). The exact error message is:
>>> import cairo
Fatal Python error: Interpreter not initialized (version mismatch?)
Abort trap: 6
and then python exits.
It would now seem that the issue is related to the framework build of python. I tested it without a framework build and it worked fine.

So as to not leave this question dangling ... I wanted to follow up with my resolution and learning points:
As noted above there was an incompatibility with my version of OSX and a gcc compile flag called -march=native. In a later version it was coming up as -march=core2. This pretty much fixed itself with compiler/version changes after cleaning up my machine.
For years I have had quite a mess with all of my various MAC OSX installs - and accepting the "migration option". Two machines ago - I installed the python binaries for versions 2.4, and 2.5, Then eventually went to macports for various reasons. Then eventually went to homebrew. When I went to homebrew I tried to clean things up by hand (but of course this can be challenging). To make matters worse - everytime I have gotten a new mac (2 times) in the last 6 years I take "the migration install" option and this pushes the mess forward and makes it worse. So as I started looking into things further - I had various installs of python, with different versions - mac-native, python-native, mac ports, homebrew, and probably even others too on my system. So my best guess is that cairo was somehow finding one of these and trying to build against it.
I finally solved this by deleting a bunch of old python installs by hand and then starting over with a fresh virtualenv and homebrew install of python 2.7.
WARNING: I don't think that this is the smartest way to go. I was careful not to delete a version of Python that I thought came native with OSX Lion (I think it is 2.6) - but it is not clear how it may potentially effect some other things that may have depended on older mac installs of python. I ended up deleting a 2.3, a 2.4, and two different 2.5s - along with various links in some places. WHAT A MESS! Unless you are absolutely sure of what it is you are doing (which I was not) I would not suggest this approach. I was basically trying to kill 6 years of python install crud that has collected.
To be safe I probably should have started with a fresh OSX Lion install and then added my homebrew version and went from there. I will likely do this in the near future.

Why does the pip installer expect gcc-4.2 to be the name of the gcc compiler in OS X Lion?

When installing packages in Python using pip, I came across the following error:
unable to execute gcc-4.2: No such file or directory
Clearly, pip is trying to use gcc-4.2 which is not in any of the binary directories, namely /usr/bin. After looking around this site and others, I have found that many others are suffering from the same issue. However, gcc is updated to version 4.2 in OS X Lion and this is not a version problem, rather, gcc is just called gcc, not gcc-4.2, under /usr/bin, and is symlinked to llvm-gcc. After adding gcc-4.2 in /usr/bin as a symlink to gcc, pip was able to install everything successfully. Why is it then, that pip is looking for gcc-4.2 and not gcc? Is this the fault of pip, OS X Lion, or the packages within pip that are trying to install themselves with gcc-4.2?
Finally, is my symlink hack the right thing to do in this situation, or should I have fixed this some other way?

Your simlink hack is the right solution for now. Ultimately the people who support pip for the platform need to stop using explicit versions of the compiler that way. It was a bad idea to begin with and will only be worse as compilers on the platform change.
Contrary to Milad's answer there are other solutions to determining version in the host compiler and your solution will work until the people who support pip on the platform fix their code.

You symlink hack is the right solution for you. pip is just trying to ensure that it is being installed using the right version of GCC. Since your computer is equipped with that version, it is safe for you to point it to your available gcc as the one it is looking for. But if, say, you had gcc-4.1 your installation might have gone places it shouldn't have.

MySQL-Python Installation Error: Possible Architecture Incompatibility?

I am attempting to set up my Django virtualenv production environment on a Linux shared host server. Installing python packages using pip goes fine until I try to install Mysql-Python, which crashes. Does anyone know why this is failing? Looking through the error log, I think it's an architecture incompatibility between the package and my python installation because of these lines:
/usr/bin/ld: skipping incompatible /usr/lib/libc.a when searching for -lc
/usr/bin/ld: warning: i386 architecture of input file build/temp.linux-x86_64-2.4/_mysql.o' is > incompatible with i386:x86-64 output build/temp.linux-x86_64-2.4/_mysql.o: In function _mysql_field_to_python':
I was told the server is 64-bit and is running Python 2.4, although I'm not sure how to double-check the former. Ive been googling this issue for several hours but I've only found references to install/import errors on macs. I'm thinking perhaps I need to compile a different version of MySQLdb instead of just doing pip install -E myvirtualenv MySQL-python but I'm unsure. Any help is greatly appreciated.

If you can't get the same architecture through pip or your package manager, you will probably need to either recompile Python (which you might consider anyway -- Python 2.4 is old), or MySQLdb.
Unfortunately, a lot of Python libraries are not cross-compatible between i386 and x86_64 -- I've actually had exactly the same issue with HGSubversion (the actual issue was with subvertpy, but I needed that for hgsubversion) and cx_Oracle. My solution was to downgrade Python to 2.6 for i386. Stunk.