[Python-Dev] Distutils thoughts (original) (raw)
Greg Ewing greg.ewing at canterbury.ac.nz
Fri Apr 21 10:34:58 CEST 2006
- Previous message: [Python-Dev] Raising objections
- Next message: [Python-Dev] Distutils thoughts
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [Python-Dev] Raising objections
- Next message: [Python-Dev] Distutils thoughts
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]