Before I complained about why .pth files are not processed in files on in your $PYTHONPATH. I got a few pointers in that regard, thanks for them. And now I know why it doesn't happen: you can import foo, bar; foo.do(); bar.harm() inside a .pth file. Since this happens also when system programs are executed a user can effectively do anything they want, just imagine a python script setuid root. One could argue a script like that should start using #!/usr/bin/env python -S but still.

So the solution is described in the easy_install documentation. Create a $PREFIX/lib/python2.X/site-packages/altinstall.py with the malicious import statement in forcing the user's path to be processed for .pth files. Ok, that introduces the above mentioned security hole. You can also do it entirely safe (and while only being a user) and create a virtual python in your home directory, which is as I understand it a symlink farm to the system python. A bit a crude hack I think but it works I guess.

Having that out of the way I experimented a bit with the setuptools themselves (while attempting to install TurboGears, which I eventually succeeded in). So here are my initial remarks about it:

• What an idea to name the frontend easy_install! I didn't really find it too easy either... altho that may be related to the fact that I don't like magic unless I fully understand the said magic.
• It's still very much in development, options change all the time and some eggs need more recent versions then what I have on my system.
• Using the bootstrap module, as one egg claims my setuptools is too old, it starts to download a new Python! I've got that installed thanks. (oh yeah, it also failed trying to compile python, but that's almost understandable.)
• My view is that distutils and setuptools try to replace make and autoconf/automake. So why not follow their lessons? Why do you need an explicit EGG-INFO available on the system? Can't you test it? That would be much more backwards compatible.
• Also missing from make: uninstall. You can expect to be dropped in /usr/local or ~ so you need to make sure you can delete your own files there again.
• There's no way, other then unzipping and checking EGG-INFO by hand, to figure out the dependencies.
• Lastly my killer bug: we live in this modern day and age where we don't trust anyone, yet there's no integrated gpg signature checking! It just downloads stuff from PiPy (or wherever you've pointed -f at)! Yes, I know it only does this during usage of easy_install and not at normal runtime, but that's not an excuse!

I feel like I've ranted too much already and realise people have been working hard on this. While I'm not too enthusiastic I can see some of the merits. In a later post I hope to outline some ideas I've had to solve some of my problems. In an ideal world I'd do some coding too, but I know I don't have lots of time. From what I've been thinking up so far most is possible with the current setuptools infrastructure, which is good as they are being adapted by many people. Only gpg signing will need people to learn a new habit, ideally setup.py will ask for this at some time in the future.