One of the epic conflicts of our time is being waged between two software design philosophies (bear with me here). Those who follow Design Philosophy A trust their users. Software is designed to be transparent and easy to inspect. Users are provided with simple and direct ways to control behaviour, and their choices are respected. Software developers avoid guessing the user's intent, since users can be trusted to do the sensible thing themselves. Those who follow Design Philosophy B think their users are idiots. Software is therefore opaque and difficult to inspect, because users wouldn't understand what is going on, and should be prevented from even trying. The developer's guess is always more trustworthy than the user's command. Users are robbed of options, because if we give the user too much control, they'll just fuck things up.
Philosophy A has given you the open source movement, Unix and the Internet. Philosophy B has given you the Microsoft Paperclip, DRM and an endless stream of clueless MCSEs. Philosophy A stands for open standards, free information exchange, and user control. Philosophy B restricts how you can use information stored on your own computer, violates your privacy, and puts the interests of software makers ahead of that of the user. In corner A stands Richard Stallman, Linus Torvalds and Theo de Raadt, dressed in light and armed with flaming swords. In corner B, wreathed in shadow, stands Bill Gates, a cohort of ignorant greedy politicians and a dark army of patent lawyers.
It is against this epic background that I invite you to consider another player on the side of darkness: setuptools. No, I don't think Phillip J. Eby is out to take control of your computer and leech your bank account details (though you might well prefer this to his attempts to de-activate your loser circuit). I surely do believe, though, that he thinks you are an idiot. Because setuptools, again and again, makes some decidedly Philosophy B design decisions. Witness:
- Setuptools is nosy. It deduces things magically from the version control system you use, so when you enter the Brave New World of distributed versioning, all your build and distribution scripts silently malfunction.
- Setuptools is needlessly opaque. Eggs break simple transparencies we currently take for granted - for example, we lose the ability to trivially inspect installed libraries with a pager, or to easily list the contents of an installed module. They also complicate more subtle things - because eggs are compressed, project data file access becomes a pain. If you need direct file access, you need to use even MORE setuptools magic to unpack project data files to a temporary directory.
- Setuptools is obstinate. It will automatically insert .eggs at the head of your sys.path to make sure they get imported in preference to any existing libraries. If I insert something into sys.path (say, for instance, to run a test suite against the development version of my library), I do NOT want my distribution mechanism to over-ride me. And no, using the setuptools development mode magic is not a satisfactory answer.
This type of intrusive design is disrespectful to users. Whenever you prefer to trust your own imperfect guesses, rather than letting the user specify what they want, you are disrespectful to your users. Whenever you needlessly make a system obscure to inspection, you are disrespectful to your users. Whenever you allow your software to spill beyond its rightful bounds (by, for example, getting intimate with my version control system), you are disrespectful to your users.
I believe that most people use setuptools because it provides a few simple pieces of functionality that could easily be added to distutils without the dross and bad design. Grafting dependencies and better package data management onto distutils would go about 80% of the way to meeting my modest expectations. Sadly, in one of those minor tragedies that life is so full of, it appears that setuptools wins by default, simply because the problem domain is so goddamn boring that no-one else has bothered.