It turns out that by default, on Leopard, Python 2.5 looks at ~/Library/Python/2.5/site-packages for Python modules. The problem is that nothing installs there by default. However, distutils (and setuptools) will read settings from ~/.pydistutils.cfg allowing you to configure some default settings for the install and easy_install commands. After a little bit of work, here’s the final result:
[easy_install]
# set the default location to install packages
install_dir = $HOME/Library/Python/2.5/site-packages
[install]
install-base=$HOME
install-purelib=$HOME/Library/Python/2.5/site-packages
install-platlib=$HOME/Library/Python/2.5/site-packages
install-scripts=$HOME/bin
install-data=$HOME/Library/Python/2.5/share
install-headers=$HOME/Library/Python/2.5/Headers
Now I can worry less about what’s going to happen with my Python modules the next time I upgrade.
I’m very excited to be attending this year. I wanted to attend the last couple of years, but had some family matters to attend to. I’m hoping to learn a few things and run into a few people while I’m there. If you haven’t signed up already, click the badge and do so!
A few of us at work are working on a fairly sizable equipment control application. Because various pieces of the equipment are pluggable and a single piece of equipment can actually perform several different tasks, we broke the equipment down in terms of interfaces. So far, that has been a great decision… until yesterday. Continue reading ‘Where interfaces fall down…’
Some of the issues that I constantly face is the question of where a project is at, how the project is doing overall, and whether or not the employees are following the company’s coding and release standards. Those aren’t easy questions to answer. Projects are involved and have many dimensions. The requirements change constantly, as do the goals of each milestone. However, I wanted a way to take a snapshot of a project… and not just for me, but it’s developers too. The idea being to present a bunch of graphs showing various features about their project, and it’s “state.” So, one morning, I sat down with Python and Trac and developed Dashboard. Continue reading ‘A dashboard for Trac…’
One of the things I miss most about CVS is knowing the full history of a file. By that, I mean being able to use cvsgraph to map out where a file has been. The releases, the branches, the tags, everything. From a configuration management perspective, this feature was awesome. You could easily identify where a particular problem existed, and which versions were affected pretty easily. With Subversion, that’s a little more complicated to do. Subversion doesn’t have branch and tag names as first class citizens. So the only way to really keep track of the revision tree is to generate your own database of that information, and walk the node graph. It’s painful. Continue reading ‘Graphing revision trees…’
I’m a big fan of SCons… mainly because it’s based on Python, and that allows me to handle a number of weird cases that I must deal with (everything from building drivers to embedded code). However, it’s not without it’s warts. Recently I discovered that you really need to be judicious with your use of Environment(). I didn’t feel I was creating all that many of them, and to be honest, I really wasn’t. The symptom I was seeing was that builds of only a few files would take 41 seconds to complete. After firing up the profiler, I discovered that the problem was the roughly 3600 calls to WhereIs, most of which used my default path. Unfortunately, that also has a network drive in it (so that I always have access to my tools, no matter which computer I use). The end results was that the bulk of the time was spent searching on the network drive for a gamut of tools (several hundred of them!).
I went back and fixed up all of the Environment calls to pull only the tools that I needed, and the build time dropped from 41 seconds to 5.8 seconds. So, when creating your construction environments in SCons, beware of what you’re asking for.
I’ve been reading some posts about Guido’s pronouncement that Django is the Python Web Framework to use at SciPy ‘06. I’m not sure that’s really good for the community, and I’m not sure it’s a good thing to endorse it that way. Continue reading ‘Django: The Python Web Framework?’
Then you need to check out this link: http://mail.python.org/pipermail/python-list/2001-February/030814.html. It incorporates creating a pid file, controlling the daemon (start, and stop), and doing the work of actually daemonizing and installing signal handlers. It’s nice snippet of code to work from if you ever need to create your own daemon. I needed to do something like this for work, and used the Python Cookbook recipe to daemonize, but took a quick look at this for the signal handlers to install and ignore. Continue reading ‘Need to write a daemon in Python?’
It amazes me how much Python keeps improving as a language. I’m continually impressed by the community, and their desire to implement an enhancement to the language in a well thought-out, and public manner. When the opportunity came to take the new Python 2.5 beta for a spin, I couldn’t resist. Continue reading ‘Testing Python 2.5!’
Slated for inclusion in Python 2.5, ctypes offers a foreign function interface (FFI) for bring shared libraries in, and wrapping them up so that you can access them through Python. It’s actually an amazing piece of work. It supports the shared libraries on every major platform, and makes it a snap to gain access to a few functions that you may need. I recently found that we’ll need the ctypes module for a project that I’m working on (I need it for PyVISA), so I also used it solve another problem: getting the amount of free disk space under a certain path.
Continue reading ‘Python’s FFI: ctypes’