Please stop using setuptools

(at least exclusively, for now...)

Here is my 'user experience' with setuptools, the installation tool used by Routes. Please note that Routes is not the first package that I have used that requires setuptools. It is just the one that put me over the edge.

[Updated with much feedback...]

From the Download page of Routes:

 Download then run:

      python Routes

  Or if you already have Easy Install:

      easy_install Routes 

Hmmm, I might already have easy_install installed so let's give that a whirl:

$ easy_install Routes bash: easy_install: command not found 

Ok, that's not too surprising, let's go for the

$ wget 
08:31:50 (95.53KB/s) - `' saved [8189/8189] 

And now to run it:

$ python Routes 
Searching for Routes Reading 
Best match: Routes 1.1 
Processing Routes-1.1-py2.4.egg 
Moving Routes-1.1-py2.4.egg to /usr/lib/python2.4/site-packages 
error: /usr/lib/python2.4/site-packages/Routes-1.1-py2.4.egg: 
  Permission denied 

Ok, my bad; I'm on my hosted site, can't run as root so I'll add --prefix=$HOME.

$ python --prefix=$HOME Routes 
usage: [global_opts]
cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...] 
or: --help [cmd1 cmd2 ...]
or: --help-commands 
or: cmd --help

  error: option --prefix not recognized 

Uhmmm, whadd'ya mean --prefix isn't recognized? You're telling me this is a setup tool that doesn't understand the common --prefix parameter?

$ python --help-commands 
usage: [global_opts]
cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...] 
or: --help [cmd1 cmd2 ...]
or: --help-commands 
or: cmd --help

  error: option --help-commands not recognized 

What the @#$$#%#?!! You just told me --help-commands was a valid option! Fine, I'll try --help and see if I get any better results.

$ python --help 
Global options:
--verbose (-v)  run verbosely (default) 
--quiet (-q)    run quietly (turns verbosity off) 
--dry-run (-n)  don't actually do anything 
--help (-h)     show detailed help message
.... Lot's of other stuff ....  

No prefix. Lot's of other stuff. No --prefix. Now there is an --install-dir, but it is rather poorly documented. Does that mean the absolute directory, or can I just point it to ~/lib/ and it will automatically find ~/lib/python2.4/site-packages? I'll be careful and give it a full path.

$ python -d ~/lib/python2.4/site-packages/ Routes
Searching for Routes
Best match: Routes 1.1 Downloading http://cheeseshop.python.o...fbf398
Processing Routes-1.1-py2.4.egg 
Moving Routes-1.1-py2.4.egg to /home/jcgregorio/lib/python2.4/site-...

  Installed /home/jcgregorio/lib/python2.4/site-packages/Rou...egg

  Because this distribution was installed --multi-version or 
  --install-dir, before you can import modules from this package in 
  an application, you will need to 'import pkg_resources' and then use 
  a 'require()' call similar to one of these examples, in order 
  to select the desired version:

  pkg_resources.require("Routes")  # latest installed version
  pkg_resources.require("Routes==1.1")  # this exact version
  pkg_resources.require("Routes>=1.1")  # this version or higher 

This might look like success, except that I had to install this locally, which I could do easily with the old package by adding --prefix. Now with this 'new' and 'improved' installer I can't just do import routes but instead have to use this new pkg_resources.require() call? Are you seriously suggesting that how I use a library is now dependent on how I installed it?

This is not success.

I have seen success before, it looked nothing like this.

This is failure.

I start again from scratch, deleting everything.

Pull the sources for Routes from the subversion repository and 'mv' the routes directory to 'site-packages' and cross my fingers.

All the unit tests pass. Everything works.

Note to all Python library developers: Please, please, please stop using setuptools. Or if you want to use setuptools, please do it in addition to a standard distutils based setup. The setuptools project is currently listed, by the author, as being in alpha. I am sure Phillip J. Eby is hard at work on making setuptools better, and I look forward to all the things it will do when it's done. But it is not done, and you, as a library developer, aren't helping the situation by using a tool that isn't finished.

Update: While this post was ostensibly not about setuptools but about those who would force an alpha level installer on the world, my post seems to have sparked some activity. You can follow this thread for more details. I'm impressed with the quick responses and the obvious commitment of those involved to making setuptools better. I'll give the setuptools author Phillip J. Eby the final word.