[Python-Dev] Distutils thoughts

[Greg Ewing]

While we're on the subject of distutils revision, here
are a few things I've encountered about distutils which
seem less than desirable.

* There doesn't seem to be a way of supplying options
   on the command line for anything except the top-level
   command. Sometimes, e.g. I want to do an "install" but
   override some options for the "build_ext" that gets
   invoked by the install. But distutils won't let me,
   because those options are not recognised by the
   "install" command itself.

   If I try to get around this by doing a "build_ext"
   explicitly, then "install", the build_ext gets done
   again the second time around, without my options.

   I know I can do this using a config file, but the
   details of that don't seem to fit in my brain, and
   I have to go looking up the docs. Come to that,
   almost none of distutils seems to fit in my brain.
   Whenever I go to write a new setup.py I have to
   go and read the docs to remind myself what it's
   supposed to look like.

* It seems to be next to impossible to override some
   of the options that get passed to the C compiler.
   For Pyrex I'd very much like to be able to turn off
   the -Wall that it seems to insist on using, but I
   haven't been able to find a way. Last time I tried,
   I got lost in a maze of twisty method calls, all
   alike.

* The mechanisms for extending it seem clumsy. Since
   there's an Extension class, the you'd think the
   obvious way to add support for Pyrex would be to
   define a PyrexExtension type that embodied all the
   necessary knowledge to deal with a .pyx file. But
   that's not the way it seems to work. The current
   Pyrex distutils extension (which I didn't write)
   works by hijacking a pre-existing method designed
   for processing swig files. If that's really the
   cleanest way it can be done, something is badly
   wrong with the design.

   This is what I meant when I said I'd like a more
   Scons-like approach. Someone complained that Scons
   was too magical. I don't necessarily want it to
   behave exactly like Scons, but just to have the
   functionality divided into independent parts that
   can be composed in the manner of Scons, so that I
   could add a component for processing .pyx -> .c
   that builds on the existing components for dealing
   with .c files, and do it in an obvious and straight-
   forward way (and hopefully without having to be
   excessively Dutch in order to see the obviousness
   of it:-).

--
Greg