ndanger.organism

Next in the continuing series of Lest I Forget Again–in which I blog things that I should know but keep forgetting–installing the Python packaging tools.

As of February 2011 it looks like distribute, pip and virtualenv are the tools of choice.

Below is what I did for the combination of Windows 7, cygwin and the Windows (not-cygwin) binary release of Python 2.7. If you want real instructions you should check out The Hitchhiker’s Guide to Packaging (THGTP), especially the section on installation.

Install distribute

distribute includes setuptools and easy_install which you need to install pip. This is as easy as.

$ wget http://python-distribute.org/distribute_setup.py
$ python distribute_setup.py

This downloads the distribution archive to a temporary folder and installs it so you don’t even muddy up your cwd. You’ve now got the distribute in your Python Lib directory and easy_install.

Install pip

pip can be installed directly by easy_install.

$ easy_install pip

I extracted the tar by hand because I’d already downloaded it, but for future use easy_install is a better bet since it will get the latest version.

pip also comes built in to virtualenv (see below) but I prefer to install it standalone.

Install virtualenv (optional)

Several packages I need (e.g. cx_Oracle) don’t install via pip so virtualenv isn’t as handy for me. Still a nice idea for apps that you plan to ship, I used it for some pre-pyramid pylons stuff.

So cx_Oracle installs easiest as a binary package against a Python Windows binary. But since cmd is awful, I only ever run bash on cygwin. Unfortunately this combination of Win32 Python running on cygwin leads to a bug in virtualenv: it doesn’t install the activate script.

Last year I wrote a patch to go with the bug but this time I wanted to try the power of distributed source control so I made a BitBucket patch queue (read more about Patch Queues here).

$ hg qclone https://bitbucket.org/dgingrich/virtualenv-cygwin32
$ cd virtualenv-cygwin32
$ hg qpush -a
$ python setup.py install

Profit!

We all know Windows is a ghetto (at least for developers); I just googled for confirmation. Unfortunately I’m stuck there because of work and have been using cygwin to make things easier.

Unfortunately I’m beginning to think cygwin is a ghetto too. You can compile some source, but there are enough differences to be annoying. Specifically you can’t compile libraries to link against other windows apps (like for Python & Haskell libraries) and the path wrangling & soft links break in any native app. It’s only nice if you don’t leave it’s confines.

So maybe a better analogy would be that cygwin is like having a really nice loft in a bad neighborhood.

In contrast MinGW seems more interested in making Windows habitable. Maybe it’s like bike paths & community gardens?

Anyone have any experience with MinGW? I think all I really need is the GCC tools, ssh and bash.

PS: and yes I’ve thought about VMware, etc. But I have to release under Windows anyway, so there’s no point having to maintain two environments. I do have an Ubuntu laptop but I never end up using it.

Cygwin‘s cygstart.exe is amazing. It opens data files as though you clicked on them in Windows Explorer. Best of all this including folders: cygstart mydir opens up a view of the directory. I’ve got mine aliased (actually a symbolic link so I can use it from eshell) to op. I started off with it aliased to open but I used it enough that the 2 keystrokes were worth it.

$ ln -s /usr/bin/cygstart.exe ~/bin/op

It’s cool that Cygwin includes an XWindows server, but, since I’m not running graphical programs remotely, I’ve never really seen the need to use it. But I really miss one thing: xterm.

I can get 80% of the way by using Launchy to start new cygwin shells. Unfortunately, the next 10% is important: environment. Xterm remembers where you are:

The new window starts in the src directory, right where we were working before. While avoiding a cd is nice, it’s really an advantage when combined with bash-ssh. A new cygwin shell starts in non-ssh mode, requiring a fresh login.

We can get this next 10% with cyg, a 2 line batch file:

@echo off
start bash

All it does is call start on the bash executable (which is already in my path).

So you can go switch to ssh mode, change your directory, and run cyg (1) and have those changes reflect in your new window (2). (I type cyg & out of habit–& runs a process in the background in *nix–but just cyg works fine). This matches my ADD work-flow: I can be in the middle of editing locally when I realize I need to clean up some temp files on the server. I launch a cyg, ssh to the server, do my deed and return without losing my place.

Using a batch file is also what produces the visual differences (3). At first I was annoyed, but it turns out pretty handy: I can easily tell my “main” window from my “omg I have to pop my stack right now” windows. Telling the windows apart is also important because there’s another limitation of cyg and bash-ssh. If the main window is closed, it takes ssh-agent with it, the cyg window needs an ssh password on each connect (though this is arguably better than xterm, which takes down all windows it launched. Oops.) (Also check out my awesome freehand text. Not bad considering I did it using a nipple.)

Scratch my back

The last 10% I’d like is the ability to launch apps in a new window. Something like

$ cyg "man rsync"

And have that launch a new window and automatically run man rsync. I played around with % variables but couldn’t get anything working. I haven’t yet written a Python script to do it, and I’d like to keep it that way.