Ok, I confess: As a core Python contributor, and an embedder of Stackless Python into a large application, I don’t often work much with the installed, vanilla version of python that the world at large knows and loves.
But a recent comment to one of my posts here prompted me to have a look at an off-the-shelf library to visualize graphs. I’m currently working on an idea that involves binary trees and I thought that using Python for prototyping and visualizing my problem in python instead of nitty-gritty C would make perfect sense. So this is where my journey started. This is the tale of a software engineer installing a Python application from the internet.
So, a fresh install of Python. I got the latest x64 binaries of python 2.7 from python.org and installed it. This I’ve done lots of times and it just worked. No problems there. But what about installing the software?
The project’s home page said that I should “pip install objgraph” to install the software. Knowing that this is supposed to be a command line, I went ahead and tried it, fully expecting it not to work. As it didn´t. So, something else is required.
What is this “pip” then? Googling for it turned up this page: http://pip-group.org/v2/index.html. Not what I expected. ”pip python” then: http://pypi.python.org/pypi/pip. Yes, an “easy install replacement.” Seems like it fits the bill. Then how do I install it? The page doesn’t say. It says a lot about pip, but not how to install it. but there is a “Downloads” link, which I follow to find a .zip file which I download.
Now, I´m a software engineer, and a Python veteran, so I know enough to unzip this file into a temporary directory. I also find a “setup.py” file in there and so, of course, I open a command shell and type the following:
(notice how I have to specify the full path to Python. The installer doesn’t add Python to the path for me. Tedious.)
Imagine my lack of surprise when my Python complains about not finding something called “setuptools,” then.
Ok then, back to the drawing board. Obviously, “setuptools” are required to install and they appear to be yet another external package. Google brings me to this page: http://pypi.python.org/pypi/setuptools
This time, installation promises to be simple. There is a windows .exe installer. I download and run the “win32-py27.exe.” Again, I am not particularly surprised when it fails to find a python 2.7 installation. After all, I elected to install the 64 bit Python, since my computer speaks 64 bits natively. Reading through the page and grepping for “x64″ led me to conclude that I should download the “source” version of setuptools. So, again, I draw on my engineering skills, download and unzip and then “c:python27python.exe tmpsetuptoolssetup.py install” as suggested for win64. And it works.
Now then, back to installing pip. This time around, “c:python27python.exe c:tmppipsetup.py install” does the trick. The script seems to indicate a successful execution.
So then, can I start to “pip install objgraph?” Nope. there is no “pip” in the path. Okay then, well, “pip” is a Python module, isn’t it? Shouldn’t I then just type “c:python27python.exe -m pip install objgraph?” No luck either. Python informs me that “pip” is a package and cannot be run like that.
Okay, I know what is going on. There is a .py script somewhere, pip.py that I need to run. The instructions are written for a Unix user that has the directory in its PATH and the file has the magic #!python in the first line. Yes, I used to be a unix guy. So, where is this file then? Looking closely, I finally find pip.exe under c:python27scripts. So, finally:
c:python27scriptspip.exe install objgraph
This works and installs the library. Great!
But what next? The objgraph page recommended i use “graphwiz” for the spiffy graphics, specifically the “xdot” package. So I install (using pip.exe) xdot, only to find that it can´t run because it is missing the “gobject” module.
And, at this point we branch off on a different Odyssey involving GTK+, PyGTK, PyCairo, PyGobject and Graphwiz that is too long and painful to recount. Suffice to say that I gave up.
There are a few main points that I’m trying to make with all this. Here they are:
- Installing python on a windows machine doesn’t add it to the PATH. Also, there are no automatic shell associations. You have to know how to run your python scripts from the command line.
- There is no simple starting point to start installing packages. At the very least one has to locate and install setuptools, which is not obvious how to do, at least if one has made the mistake of installing a 64 bit version of Python. And then one has to locate and install the friendlier “pip” installer using a lengthy command line.
- Most of the instructions encountered assume a unix environment. Perhaps the experience is smoother on unix. Perhaps not.
This wasn’t the first time I tried to install a Python package. And I admit that I am being deliberately obtuse to illustrate a point. But every time I go through these moves I am amazed at how cumbersome it is. I am a computer veteran of the Jupiter ACE era and know my onions but there are people out there that don’t and who will be turned away much earlier than I was and that is a shame.
But there is also another issue here that I find unsettling with the whole process. Even assuming that all goes well, I have the proper install tools and know how to use them: Whenever I want to go and check out some python project or other, I find that I have to install it and what is more, install all its prerequisites. And so on ad infinitum. Very soon, you find that you have installed all kinds of modules and packages, permanently modifying your python environment. There is no obvious cleanup mechanism and no way of tracking dependencies. I am loath to do this because I always have this uneasy feeling that my Python install is somehow tainted after doing this.
So, this blog is digressing into another about packaging so I will stop here and rant about that at a later date.