Is setup.py a "good thing"? (long)

[Andrew Kuchling]

support @ internetdiscovery.com (Mike Clarkson) writes:
> #1) Someone documented what setup.py is supposed to do, and how it is
> supposed to interact with configure and make.

I've written most of setup.py, so I'll comment.  It arose from the
observation that most people don't edit the Module/Setup file and turn
on all the modules they could possibly run.  This is annoying because
there are bunches of modules there that are useful, but you can't
really count on them being very widespread -- how many people
uncomment, say, the syslog module when they compile from source.

There was some work done for 2.0, and during the 2.0->2.1 development
process, on making configure check for the BSDDB library, several DBM
variants, and curses, but this didn't approach the number of modules
available in Setup, and the process of supporting a module -- hack
configure.in, which in turn built a Setup.config file -- was messy and
complicated.  (This was before the Makefiles were rewritten to be
non-recursive and the build process tidied up in various ways.  It's
quite possible that perhaps this will make adding modules to configure
and setup.py is no longer such a burning need.)

> #3) Python configure had the  configure options --with-tcl-config and
> --with-tk-config so I could say explicitly where what I want is. This

If a module is enabled in Modules/Setup, then setup.py won't try to
build it, so you could just enable Tkinter there with whatever options
are required.  

--amk