[Python-Dev] Distutils thoughts

Fri Apr 21 10:34:58 CEST 2006

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