Ian Bicking: the old part of his blog

Re: site-packages Considered Harmful

Totally agreed.

One of the big things I have to deal with are black-box "appliance" installations of hosts. In this case, my application should not have to modify site-packages to install things it needs (like sqlobject, postgresql packages, etc) on the remote host. Once I modify anything outside of my $CWD (i.e: the installation path) I have altered the system in such a way that in all future installations I have to walk down into that site-packages directory and check for versions/updates/etc.

I typically work around this by dropping everything into a /lib directory of my app - and then hacking sys.path to suck in the directory relative to my applications path. This makes execution outside of that directory difficult as I have to assume that /lib is relative to the binary location. I realize there are other ways around this - but have something built into the interpreter that says "I am only going to check dir X for modules (of a set revision)" then otherwise forcing users/applications to hack with sys.path and the $PYTHONPATH is sort of cludgy.

I don't have any good alternatives - but I do know that in addition to having to work with an appliance where I shouldn't be modifying anything outside of $MYDIR and then potentially working with multiple versions of Python on the same machine (2.3/2.4) with the current site packages methodology is really frustrating.

Comment on site-packages Considered Harmful
by Jesse